Антон, а для чего вообще code review по вашему?:)

На мой взгляд несколько причин может быть:
1) Если хочется увеличить Time To Market от пары дней до нескольких недель, а то и месяца
2) Если хочется перессорить программистов с равным уровнем квалификации между собой. Или потешить самолюбие "архитектора".
3) Если нужен надсмотр за джунами и миддлами, когда некогда думать над архитектурой и дизайном до того как код написан.

Это описание явно не про "сильную" с точки зрения культуры разработки команды:)

🤷‍♂️

На мой взгляд сильная с точки зрения культуры команда исключает вещи которы ее стопорят и автоматизирует рутинные операции. Т.е. по сути стремится к оптимизации процессов.

А вот список зачем это нужно "сильной" команде:
1. обмен опытом, когда твой идеальный код читают не менее крутые разработчики они могут поделиться с тобой новыми идеями, ссылками на доки и так далее
2. подстраховка, когда твой код не просто в стол пишется очень важно что бы кто-то ещё был в курсе того что ты делаешь и как оно работает
3. защита от случайностей, все мы люди и можем что-то где-то забыть

В командах где код пишется хорошо и все боли код ревью пройдены давно время на ревью - минут пять на задачу.

Если у команды нет код ревью, то она не может считаться сильной :)

Смотря в каком плане сильной:) Вообще в чём сила?:)

Недаром есть термин "грубая сила"

Если еще нет, то да, а если уже нет, то она уже достаточно сильная и на собственном опыте испытала влияние карго культа.

Вообще если немного глубже изучить тему конкретно Code Review то действительно окажется, что эта практика повышает качество продукта на выходе. Но важный момент заключается в том, что 75% проблем обнаруженных на этом этапе являются эволюционными (архитектура и дизайн) проблемами. А эволюционные проблемы намного дешевле обсуждать и чинить до того, как код вообще написан. Остальные 25% того что находится на код ревью куда проще а главное надежнее чинятся тестированием.

Код-ревью отлично помогает при бас-факторе. Не представляю ситуации, когда его "уже нет". Только временные приостановки, когда все в огне.

Предположим что у "сильной" команды код ревью добавляет к каждой задаче несколько недель времени... о чём это говорит?
1. задачи плохо декомпозированы
2. в задачах ничего не понятно
3. слишком много изменений
4. слишком мало людей которые понимают что в проекте происходит, почему он пишется так, а не иначе и есть множество разногласий

Получается пока другие не видят - всё быстро:)

Наконец Олег ты вышел к людям ))

А?

Я постоянно с людьми общаюсь:)

Что сам думаешь про code review?:) Нужен/не нужен?:)

Не оффтопы и не срачи, а чт полезное

Пришел GitHub, принес GitHub Flow, с Pull Requests (Запросами на вытягивание) предполагается что разработчик приносящий PR он по отношению к команде и к проекту в целом внешний ("чужой"). И все резко подхватили этот процесс к себе, абсолютно не задумываясь ни о каких метриках и последствиях.🙂

Нужен