Потому что я вижу для себя в этом только головную боль и трату времени безо всякой благодарности.
Если надо обучать джунов — пожалуйста, давайте четко это обозначим. Я с удовольствием проведу воркшоп и расскажу на примерах своего кода как и почему я это делаю.
Но ревью должен делать человек достаточного уровня, чтобы понимать и мой код и логику и иметь возможность квалифицированно меня поправить по делу. Т.е. чтобы и мне была польза. А так получится одна соковыжималка, а Риком я становиться не хочу.
Мой опыт говорит о другом. Когда есть деньги — можно собрать команду звезд по всему миру и выдать на гора за пол года, что до этого не могли запустить за 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а сама по себе еще не обязательно приведет к возможности получения злоумышленником новых токенов. Зависит от того, какой механизм используется для передачи токена клиенту.
Идея refresh token — это идея oAuth2, а не JWT.
И как раз этот токен предназначен для того, чтобы пользователю не приходилось вводить пароль снова и снова.
Никто не мешает вам сделать JWT токен долгоживущим, если вы по какой-то странной причине считаете это нужным.
Никто не запрещает вам добавить проверку JWT токена в черном списке, как я сказал выше.
Разница и профит в том, что вам не надо напрягать сервер авторизации для такой проверки.
Но вообще говоря, короткоживущий токен рекомендуется в oAuth2 вообще и вне зависимости от механизма валидации.
Если действительно надо, то никто не мешает добавить в процедуру валидации токена проверку его наличия в каком нибудь централизованном черном списке, если это необходимо.
Хм, так а какая альтернатива? Вы предлагаете восстанавливать сессии? А как с безопасностью?
К JWT это вообще отношения не имеет. Если безопасность не проблема — восстанавливайте сессии с authorisation server по куки (или еще как нибудь) невидимо для пользователя и открывайте ему сразу страницу его банковского счета, например.
Если надо обучать джунов — пожалуйста, давайте четко это обозначим. Я с удовольствием проведу воркшоп и расскажу на примерах своего кода как и почему я это делаю.
Но ревью должен делать человек достаточного уровня, чтобы понимать и мой код и логику и иметь возможность квалифицированно меня поправить по делу. Т.е. чтобы и мне была польза. А так получится одна соковыжималка, а Риком я становиться не хочу.
То, что вы описывается годится для рутины в каком нибудь отделении банка где последние 20 лет правят какой нибудь их внутренний опердень и звезд с неба не хватают.
Очевидно, уже был на взводе и готов послать все нафик.
Это знаете как-то однобоко, все проблемы решаются за счет программеров а менеджмент во всем белом, ах, у нас не получилось, придется зачищать.
С себя зачистку пусть бы и начинали.
Если бы я решал, кого присылает наш HR отдел нам в работнички…
На самом деле проблема не в опыте и не в джуниорах. Проблема в дебилах. И опыт это чаще всего не исправляет.
Заметьте, не он принуждал кого-то делать так и так — к нему все сами шли.
Зашибенный успех менеджмента. Кто платит за весь этот праздник щедрости?
О чем это говорит? О том, что предметно доказать проблемы в его коде не смогли.
Но зачем вникать? Можно ведь ерничать, вместо того чтобы попросить этого парня попросту ревьювить чужие коммиты. По большому счету, только этим его и следовало бы загружать.
Так что еще очень большая проблема — сильная разница в уровне у членов комманды.
Тогда выское дерево будет непременно срублено. Так и получилось.
Как то у меня не складывается воедино история о «коде, полном копипасты» и чуваке — «решателе проблем», к которому вся команда ходит консультироваться.
На чувака вешали всю жесть, в то время как другие члены команды расслаблено занимались тем, что им интересно. Что-то сложное, что может загрузить мозг на пределы рабочего времени — для этого есть Рик. Реально, чувака загнали, а потом выкинули.
Теперь, то, что делал Рик, будет стоить компании в разы, если не на порядки дороже.
Что мешали им раньше увеличить расходы и разгрузить чувака?
Мое мнение, компания потеряла нетривиального парня. И десяток посредственностей его не заменят.
1.Если у вас конфиденциальный клиент, то можно требовать отправки client_id и client_secret вместе с refresh token для получения нового токена доступа. Т.о. если злоумышленник не знает вашего секрета, то получить новый токен доступа он не сможет.
2. На публичном клиенте, если злоумышленник знает client_id и refresh token — то это все что ему нужно :-).
Но, да, я согласен, это чисто теоретический и излишне параноидальный сценарий.
Я считаю, что делать токен короткоживущим достаточно. Т.к. за то время, пока вы узнаете, что токен скомпрометирован и добавите его в некий список, он уже скорее всего устареет в любом случае.
И как раз этот токен предназначен для того, чтобы пользователю не приходилось вводить пароль снова и снова.
Никто не мешает вам сделать JWT токен долгоживущим, если вы по какой-то странной причине считаете это нужным.
Никто не запрещает вам добавить проверку JWT токена в черном списке, как я сказал выше.
Разница и профит в том, что вам не надо напрягать сервер авторизации для такой проверки.
Но вообще говоря, короткоживущий токен рекомендуется в oAuth2 вообще и вне зависимости от механизма валидации.
К JWT это вообще отношения не имеет. Если безопасность не проблема — восстанавливайте сессии с authorisation server по куки (или еще как нибудь) невидимо для пользователя и открывайте ему сразу страницу его банковского счета, например.