Каждый слой ревью замедляет вашу команду

Стартап выпускает баг в продакшен. Реакция руководства: ввести обязательное код-ревью. Через некоторое время проскакивает ещё один баг. Реакция: требовать двух ревьюеров. Затем инцидент с безопасностью. Реакция: добавить этап security-ревью. Потом несогласованность в дизайне. Реакция: добавить дизайн-ревью. Через два года каждое изменение, каким бы маленьким оно ни было, проходит через четыре стадии ревью и сливается три дня. Разработчики, которые когда-то выкатывали код ежедневно, теперь тратят на ревью больше времени, чем на написание кода.

Этот паттерн настолько распространён, что его можно считать почти законом организационного поведения: каждый инцидент порождает новый слой ревью, и ни один слой никогда не убирают. В итоге процесс ревью оптимизирован под предотвращение прошлого инцидента ценой блокировки всего будущего прогресса.

Математика очередей на ревью

Каждый слой ревью добавляет не просто время, а умножает его. Если одно ревью в среднем занимает 4 часа (не само ревью, которое длится 20 минут, а время, пока PR простаивает в очереди, дожидаясь ревьюера), то два последовательных ревью займут 8 часов. Три — 12. Четыре — 16.

Но всё ещё хуже из-за переключения контекста. Разработчик отправляет PR и берётся за новую задачу. Когда отзыв приходит через несколько часов, ему приходится вернуться к старой работе, заново загрузить контекст, внести правки и отправить снова, а потом снова ждать. Каждый раунд ревью обходится в 30–60 минут накладных расходов на переключение контекста поверх времени в очереди.

А есть и каскадный эффект. Если ревьюер А просит изменения, разработчик вносит их и отправляет заново. Теперь ревьюер Б, который ещё не видел PR, смотрит код и просит совсем другие правки. Разработчик вносит и их. Теперь ревьюеру А нужно пересмотреть код, чтобы проверить, учтены ли его замечания, но он уже переключился на другие задачи, и PR снова оказывается в очереди.

Timeline of a PR through a 3-reviewer process:
Day 1 9:00  — Developer submits PR
Day 1 14:00 — Reviewer A reviews, requests changes
Day 1 15:00 — Developer addresses feedback, resubmits
Day 2 10:00 — Reviewer B reviews, requests different changes
Day 2 11:00 — Developer addresses, resubmits
Day 2 16:00 — Reviewer A re-reviews, approves
Day 3 11:00 — Reviewer C reviews, approves
Day 3 11:30 — Reviewer B re-reviews, approves
Day 3 12:00 — PR merges
Elapsed time: ~3 business days
Actual review time: ~90 minutes total
Actual code change time: ~2 hours
Time waiting in queues: ~22 hours
Queue time is 80% of the total elapsed time.

Парадокс качества

Предположение, стоящее за добавлением слоёв ревью, таково: больше ревью означает лучший код. До определённого момента это правда, а потом тренд разворачивается.

Один внимательный ревьюер находит реальные проблемы: ошибки в логике, пропущенные граничные случаи, проблемы безопасности, спорные решения в API. Второй ревьюер иногда замечает то, что пропустил первый, примерно в 10–20% случаев. Третий почти никогда не находит ничего, что не поймали первые двое. Предельная польза от каждого следующего ревьюера резко падает.

Тем временем цена медленных слияний реальна, но нигде не учитывается. Долгоживущие ветки расходятся с main, и приходится делать ребейзы, которые сами вносят ошибки при слиянии. Разработчики объединяют больше изменений в один PR, чтобы не тратить время на накладные расходы каждого ревью, и PR становятся больше и сложнее для вдумчивой проверки. Ревьюеры устают: когда в очереди 15 PR, они пробегают код глазами вместо того, чтобы читать внимательно.

Парадокс в том, что добавление слоёв ревью ради качества может на деле его снизить: процесс создаёт стимулы (большие PR, поспешные ревью, устаревшие ветки), которые подрывают сам процесс ревью.

Что на самом деле предотвращают тяжёлые процессы ревью

Процессы ревью часто обосновывают конкретными инцидентами: «Мы выкатили баг, потому что никто не посмотрел код». Но вопрос о том, поймало бы ревью конкретный баг, отличается от вопроса о том, улучшает ли требование ревью общий результат.

Исследования эффективности код-ревью стабильно показывают, что ревью находит около 60% дефектов, в основном поверхностные проблемы вроде именования, форматирования и очевидных ошибок в логике. Глубокие архитектурные баги, проблемы конкурентности и уязвимости безопасности редко ловятся на ревью, потому что для их поиска нужно понимать всю систему, а не только дифф. Ошибки, которые вызывают инциденты в продакшене, непропорционально часто относятся к тем, что ревью не замечает.

Что реально предотвращает инциденты в продакшене, так это тестирование, мониторинг и возможность быстро выкатывать и откатывать изменения. Команда, которая быстро работает с хорошими тестами, фича-флагами и мгновенными откатами, будет иметь меньше инцидентов, чем команда с четырьмя слоями ревью, но без интеграционных тестов и с часовыми циклами деплоя.

Правильная доза ревью

Код-ревью полезно. Для большинства команд оптимален один ревьюер на PR с чёткими ожиданиями о том, на что именно он смотрит. Вот как это выглядит на практике.

• Один ревьюер, а не два или три. Первый ревьюер находит около 80% того, что вообще способно найти ревью. Второй добавляет минимальную пользу при значительной цене. Процессы с несколькими ревьюерами оставьте для действительно рискованных изменений (миграции баз данных, изменения авторизации, модификации публичного API).
• Ограничьте время в очереди на ревью. Если PR не просмотрели за 4 часа, это сбой процесса, а не проблема ленивого ревьюера. Команде нужно расставить приоритеты по ресурсам на ревью или смириться с тем, что разработчиков у неё больше, чем может обслужить процесс ревью.
• Маленькие PR вместо больших. PR на 50 строк получает внимательное ревью за 10 минут. PR на 500 строк получает поверхностное ревью за 30 минут. PR на 50 строк проверяется лучше, несмотря на меньше времени. Ограничения по размеру (максимум 200–300 строк) эффективнее повышают качество ревью, чем добавление ревьюеров.
• Пропускайте ревью для низкорисковых изменений. Изменения конфигурации, правки текстов, обновления зависимостей, добавление тестов не требуют такой же строгости, как изменения бизнес-логики. Определите категорию «низкий риск» и разрешите самостоятельное слияние с ревью уже после него.
• Автоматизируйте то, с чем лучше справляются машины. Линтинг, форматирование, проверка типов, покрытие тестами: это задачи ревью, которые машины выполняют быстрее и стабильнее людей. Не тратьте внимание ревьюеров на то, что уже проверяет CI.

Культурная проблема

Сокращать слои ревью трудно, потому что это ощущается как снижение безопасности. Никто не хочет быть тем, кто выступал за меньше ревью прямо перед production-инцидентом. Это скорее проблема организационной культуры, чем техническая.

Помогает такой взгляд: ревью это один из многих механизмов безопасности, и его отдача снижается. Добавлять четвёртого ревьюера, чтобы предотвратить баги, значит то же самое, что вешать четвёртый замок, чтобы не допустить кражи. Первый замок делает основную работу, а каждый следующий добавляет неудобств без пропорциональной защиты. Вы же не будете вешать четыре замка. Не добавляйте четырёх ревьюеров.

Команды, которые быстро выпускают код и реже ломают продакшен, обычно инвестируют в механизмы, которые действительно предотвращают инциденты: комплексное автоматизированное тестирование, фича-флаги для постепенного раскатывания, надёжный мониторинг с алертингом, откат в один клик и культуру блеймлес-анализа, которая воспринимает инциденты как возможность научиться, а не как повод искать виноватых. Такие инвестиции со временем накапливаются, чего нельзя сказать о слоях ревью.

Как убрать слой ревью

Если в вашей команде накопилось слишком много требований к ревью, вот как их сократить без паники.

Начните с измерения текущего процесса. Сколько времени PR проходит от отправки до слияния? Какая часть этого времени уходит на ожидание в очереди, а какая на активное ревью? Сколько PR одновременно висит в очереди на ревью? Эти цифры делают стоимость видимой: большинство команд в шоке, когда видят, что средний PR сливается 3 дня.

Затем проведите эксперимент. На один месяц требуйте одного ревьюера вместо двух. Отслеживайте те же метрики. Изменилась ли частота инцидентов? Изменилось ли качество кода (измеренное по частоте дефектов, а не на глазок)? Почти всегда ответ такой: инцидентов не стало больше, качество осталось прежним, а пропускная способность заметно выросла.

Цель не в нулевом ревью, а в минимальном ревью, которое сохраняет качество и максимизирует скорость. Этот минимум почти всегда меньше того, что делают команды сейчас, потому что слои ревью накапливаются через реакцию на инциденты, но никогда не убираются при оптимизации процессов. Как и в случае с созданием хорошего софта, ответ не в большем количестве процессов, а в правильном процессе.