Size: a a a

2020 October 15

AG

Andrey Goncharov in Node.js SPb
Nikolay Matvienko
+1
code review, no? ... :). Вроде решается так)
Или решается, или приводит к коллегиальному принятию не самых лучших решений)
источник

AM

Andrey Melikhov in Node.js SPb
код ревью работает на качество только при должном уровне ревьюверов. В крупной компании это невозможно, если только есть костяк лидов высочайшего уровня, которые пропускают через себя весь код.
Уж лучше проектировать безопасно и закладываться заранее на возможные проблемы.
источник

AG

Andrey Goncharov in Node.js SPb
Andrey Melikhov
код ревью работает на качество только при должном уровне ревьюверов. В крупной компании это невозможно, если только есть костяк лидов высочайшего уровня, которые пропускают через себя весь код.
Уж лучше проектировать безопасно и закладываться заранее на возможные проблемы.
И даже это не гарантия. Если эта тима суперменов столкнется с чем-то, что они раньше не трогали, то все равно можно коллегиально нарешать что-то, что потом аукнется
источник

AG

Andrey Goncharov in Node.js SPb
Зато будет повод сделать хороший блог пост и доклад)
источник

NM

Nikolay Matvienko in Node.js SPb
Большие компании, тимы суперменов, нет 100% гарантии. Да нигде нет 100% гарантии, но с код ревью риски значительно ниже. Не говоря уже о других плюсах. Но вы сами все знаете.
источник

AP

Andrey Pechkurov in Node.js SPb
Поддержание кодовой базы в адекватном состоянии это постоянный процесс и одних ревью тут мало. Нужно пересматривать и внедрять практики и новые инструменты, работать с техническим долгом, менторить членов команды и так далее
источник

NM

Nikolay Matvienko in Node.js SPb
Andrey Melikhov
код ревью работает на качество только при должном уровне ревьюверов. В крупной компании это невозможно, если только есть костяк лидов высочайшего уровня, которые пропускают через себя весь код.
Уж лучше проектировать безопасно и закладываться заранее на возможные проблемы.
B первом предложении оно работает, но во втором уже нет. Большая компания все равно делится на департаменты/аккаунты, проекты, команды. Достаточно одного лида, чтоб в команде было код ревью (время? да его капасити будет снижено по началу до 25-50% максимум). На моей практике. У нас джуны, очень быстро подхватывают лучшие практики (не говорю уже о мидлах). И если код достаточно чистый, то все наглядно и очевидно, т.к. он читаем, все по шаблонам и уменьшается его сложнось.  И эти же джуны/мидлы видя похожие ошибки в других PR, тут же комментят об этом.

В ЯМ применяете код ревью?...
источник

NM

Nikolay Matvienko in Node.js SPb
Andrey Pechkurov
Поддержание кодовой базы в адекватном состоянии это постоянный процесс и одних ревью тут мало. Нужно пересматривать и внедрять практики и новые инструменты, работать с техническим долгом, менторить членов команды и так далее
конечно, это часть процессов.
+1
источник

AP

Andrey Pechkurov in Node.js SPb
Код ревью это базовое требование. Без него просто никуда
источник

AP

Andrey Pechkurov in Node.js SPb
Причем, я не уверен, что все должно проходить через узкий набор лиц. Если в команде все опытные, то ревью может делать кто угодно. Можно поставить порог на кол-во апрувов и все
источник

AM

Andrey Melikhov in Node.js SPb
Nikolay Matvienko
B первом предложении оно работает, но во втором уже нет. Большая компания все равно делится на департаменты/аккаунты, проекты, команды. Достаточно одного лида, чтоб в команде было код ревью (время? да его капасити будет снижено по началу до 25-50% максимум). На моей практике. У нас джуны, очень быстро подхватывают лучшие практики (не говорю уже о мидлах). И если код достаточно чистый, то все наглядно и очевидно, т.к. он читаем, все по шаблонам и уменьшается его сложнось.  И эти же джуны/мидлы видя похожие ошибки в других PR, тут же комментят об этом.

В ЯМ применяете код ревью?...
конечно, но если команда варится внутри себя без сильного лидера то это скорее работает только как инструмент перекрестного владения кодом, но не повышения качества
источник

AP

Andrey Pechkurov in Node.js SPb
Это будет работать лучше, чем с несколькими незаменимыми ревьюерами. Народ будет смотреть на работу друг друга и вырабатывать общие подходы
источник

NM

Nikolay Matvienko in Node.js SPb
Andrey Melikhov
конечно, но если команда варится внутри себя без сильного лидера то это скорее работает только как инструмент перекрестного владения кодом, но не повышения качества
ЛОЛ, ну это да. Как своя маленькая планета) Да, как говорится нужна свежая кровь всегда.
источник

NM

Nikolay Matvienko in Node.js SPb
Бывает что придет мид свежий, и тут же предложит что-то новое, свежее.
источник

NM

Nikolay Matvienko in Node.js SPb
Фак, сейчас вспомнил - как он предложил ТайпОРМ)
источник

AM

Andrey Melikhov in Node.js SPb
иногда трясём команды закидывая бодрых миддлов )
источник

NM

Nikolay Matvienko in Node.js SPb
Это правильно
источник

NM

Nikolay Matvienko in Node.js SPb
Andrey Pechkurov
Это будет работать лучше, чем с несколькими незаменимыми ревьюерами. Народ будет смотреть на работу друг друга и вырабатывать общие подходы
100% и быстро развиваются. и требуют ЗП и уходят в другие компании))
источник

AP

Andrey Pechkurov in Node.js SPb
Беда-беда :)
источник

NM

Nikolay Matvienko in Node.js SPb
да, видишь все таки есть и минусы)))) сайд эффекты
источник