Да какие проблемы — код во всеобщем доступе, история коммитов и комментарии тоже. Мердж происходит только после ревью. Вы так говорите, будто кто-то не хочет вам показывать свой код… Вопрос на самом деле, как происходит мердж. И зависит ли он от подтверждения от ревьювера — джуниора. Вот это напрягает — необходимость разжевать и объяснять банальности, иногда и просто тратить время на спор с дебилом, просто чтобы твой код ушел в девелоп. Никакой отдачи мне лично такой процесс не дает. Начальство время и нервы потраченные на такие объяснения не оценит — наоборот, задержка твоего коммита на ревью идет тебе в минус. Вообщем, одна головная боль.
Я поддерживаю вариант, когда ревьювит человек с опытом и в теме. И он же подтверждает мердж. Тогда все уходит в 90% без сучка без задоринки, а если возникают вопросы — то по делу и действительно можно чему-то научиться самому.
Ну, если каждый коммит ревьювит вся комманда (почему один джуниор, пусть уж все джуниоры учатся) — это замечательно. Но как-то малореалистично. Хотя, в банке может быть и не такое. А когда времени в обрез и все заняты своим, то реально ревьювить может один. Остальные максимум тихо учиться ну и как тут сказали указывать на синтаксические ошибки.
Так в том то и дело, что это не ревью. В том то и дело, что опечатку то может такое процесс и найдет, а вот реальную проблему пропустит. Просто по незнанию.
Получается, ни ревью полноценного, ни обучения, на которое требуется время.
Или вы путаете ревью с изучением кода?
Потому что я вижу для себя в этом только головную боль и трату времени безо всякой благодарности.
Если надо обучать джунов — пожалуйста, давайте четко это обозначим. Я с удовольствием проведу воркшоп и расскажу на примерах своего кода как и почему я это делаю.
Но ревью должен делать человек достаточного уровня, чтобы понимать и мой код и логику и иметь возможность квалифицированно меня поправить по делу. Т.е. чтобы и мне была польза. А так получится одна соковыжималка, а Риком я становиться не хочу.
Мой опыт говорит о другом. Когда есть деньги — можно собрать команду звезд по всему миру и выдать на гора за пол года, что до этого не могли запустить за 5 лет потратив астрономические суммы.
То, что вы описывается годится для рутины в каком нибудь отделении банка где последние 20 лет правят какой нибудь их внутренний опердень и звезд с неба не хватают.
Я бы пожалуй уволил весь менеджмент и побеседовал бы с Риком на тему, кого оставить в команде, а с кем попрощаться. Далее, я бы попросил Рика провести интервью и набрать команду из людей, которые были бы его уровня «Энштейн» и с которыми ему комфортно и удобно было бы работать и код которых он мог бы спокойно положиться.
Так все понятно. Кроме одного. Почему уволили Рика, а не менеджмент?
Это знаете как-то однобоко, все проблемы решаются за счет программеров а менеджмент во всем белом, ах, у нас не получилось, придется зачищать.
С себя зачистку пусть бы и начинали.
Или над уровнем джуниоров :-).
Если бы я решал, кого присылает наш HR отдел нам в работнички…
На самом деле проблема не в опыте и не в джуниорах. Проблема в дебилах. И опыт это чаще всего не исправляет.
Ну так это другой случай. Вы часто ходили к этому вашему звездному чуваку за техническими советами? А вот к тому Рику ходила вся команда по всем сложным вопросам. И он брался помогать и разъяснять каждому. Даже доску специально поставил.
Заметьте, не он принуждал кого-то делать так и так — к нему все сами шли.
Ну да, грузовик вовремя не заехал, пришлось чувака увольнять самим и переписывать код с нуля.
Зашибенный успех менеджмента. Кто платит за весь этот праздник щедрости?
Я все же позволю себе усомниться что качество когда было низкое. Потому что автор как раз как бы саркастически пишет: «Of course, these bugs were happening because the users had misstated their assumptions. Of course there wasn’t any problem in his work. Of course.»
О чем это говорит? О том, что предметно доказать проблемы в его коде не смогли.
Но зачем вникать? Можно ведь ерничать, вместо того чтобы попросить этого парня попросту ревьювить чужие коммиты. По большому счету, только этим его и следовало бы загружать.
По моему личному опыту, меня напрягает, когда мой код дают ревьювить человеку, профессионально ниже меня на порядок. С другой стороны, всегда интересно мнение профессионала твоего уровня или выше, когда смотришь на предложенную правку — и просто вау, я и не подумал что так просто можно все решить.
Так что еще очень большая проблема — сильная разница в уровне у членов комманды.
Тогда выское дерево будет непременно срублено. Так и получилось.
Я бы добавил, что я сильно сомневаюсь, что его код был так уж плох.
Как то у меня не складывается воедино история о «коде, полном копипасты» и чуваке — «решателе проблем», к которому вся команда ходит консультироваться.
Полностью согласен с выводами автора статьи.
На чувака вешали всю жесть, в то время как другие члены команды расслаблено занимались тем, что им интересно. Что-то сложное, что может загрузить мозг на пределы рабочего времени — для этого есть Рик. Реально, чувака загнали, а потом выкинули.
Теперь, то, что делал Рик, будет стоить компании в разы, если не на порядки дороже.
Что мешали им раньше увеличить расходы и разгрузить чувака?
Мое мнение, компания потеряла нетривиального парня. И десяток посредственностей его не заменят.
Зависит от вашего сценария.
1.Если у вас конфиденциальный клиент, то можно требовать отправки client_id и client_secret вместе с refresh token для получения нового токена доступа. Т.о. если злоумышленник не знает вашего секрета, то получить новый токен доступа он не сможет.
2. На публичном клиенте, если злоумышленник знает client_id и refresh token — то это все что ему нужно :-).
Разница в том, что это будет обращение к внутреннему хранилищу, а не к внешнему серверу авторизации.
Но, да, я согласен, это чисто теоретический и излишне параноидальный сценарий.
Я считаю, что делать токен короткоживущим достаточно. Т.к. за то время, пока вы узнаете, что токен скомпрометирован и добавите его в некий список, он уже скорее всего устареет в любом случае.
refresh token не передается сервису и т.о. он более безопасный. Компрометация refresh tokenа сама по себе еще не обязательно приведет к возможности получения злоумышленником новых токенов. Зависит от того, какой механизм используется для передачи токена клиенту.
Я поддерживаю вариант, когда ревьювит человек с опытом и в теме. И он же подтверждает мердж. Тогда все уходит в 90% без сучка без задоринки, а если возникают вопросы — то по делу и действительно можно чему-то научиться самому.
Получается, ни ревью полноценного, ни обучения, на которое требуется время.
Или вы путаете ревью с изучением кода?
Если надо обучать джунов — пожалуйста, давайте четко это обозначим. Я с удовольствием проведу воркшоп и расскажу на примерах своего кода как и почему я это делаю.
Но ревью должен делать человек достаточного уровня, чтобы понимать и мой код и логику и иметь возможность квалифицированно меня поправить по делу. Т.е. чтобы и мне была польза. А так получится одна соковыжималка, а Риком я становиться не хочу.
То, что вы описывается годится для рутины в каком нибудь отделении банка где последние 20 лет правят какой нибудь их внутренний опердень и звезд с неба не хватают.
Очевидно, уже был на взводе и готов послать все нафик.
Это знаете как-то однобоко, все проблемы решаются за счет программеров а менеджмент во всем белом, ах, у нас не получилось, придется зачищать.
С себя зачистку пусть бы и начинали.
Если бы я решал, кого присылает наш HR отдел нам в работнички…
На самом деле проблема не в опыте и не в джуниорах. Проблема в дебилах. И опыт это чаще всего не исправляет.
Заметьте, не он принуждал кого-то делать так и так — к нему все сами шли.
Зашибенный успех менеджмента. Кто платит за весь этот праздник щедрости?
О чем это говорит? О том, что предметно доказать проблемы в его коде не смогли.
Но зачем вникать? Можно ведь ерничать, вместо того чтобы попросить этого парня попросту ревьювить чужие коммиты. По большому счету, только этим его и следовало бы загружать.
Так что еще очень большая проблема — сильная разница в уровне у членов комманды.
Тогда выское дерево будет непременно срублено. Так и получилось.
Как то у меня не складывается воедино история о «коде, полном копипасты» и чуваке — «решателе проблем», к которому вся команда ходит консультироваться.
На чувака вешали всю жесть, в то время как другие члены команды расслаблено занимались тем, что им интересно. Что-то сложное, что может загрузить мозг на пределы рабочего времени — для этого есть Рик. Реально, чувака загнали, а потом выкинули.
Теперь, то, что делал Рик, будет стоить компании в разы, если не на порядки дороже.
Что мешали им раньше увеличить расходы и разгрузить чувака?
Мое мнение, компания потеряла нетривиального парня. И десяток посредственностей его не заменят.
1.Если у вас конфиденциальный клиент, то можно требовать отправки client_id и client_secret вместе с refresh token для получения нового токена доступа. Т.о. если злоумышленник не знает вашего секрета, то получить новый токен доступа он не сможет.
2. На публичном клиенте, если злоумышленник знает client_id и refresh token — то это все что ему нужно :-).
Но, да, я согласен, это чисто теоретический и излишне параноидальный сценарий.
Я считаю, что делать токен короткоживущим достаточно. Т.к. за то время, пока вы узнаете, что токен скомпрометирован и добавите его в некий список, он уже скорее всего устареет в любом случае.