Code Review: практики и инструменты

Почему ревью замедляет и почему без него нельзя

Code review — одна из самых болезненных петель обратной связи в разработке. Вы написали код, отправили pull request — и ждёте. По данным Google, медианное время до первого комментария ревьюера составляет 4 часа для небольших изменений и до суток для крупных. В компаниях без установленных SLA это время растягивается до нескольких дней, и всё это время ваша ветка расходится с main, контекст задачи выветривается из памяти, а мотивация довести дело до конца тает.

При этом отказаться от ревью — значит потерять один из немногих проверенных механизмов распространения знаний в команде. Google в книге Software Engineering at Google описывает четыре функции code review: нахождение багов, передача знаний о кодовой базе, обеспечение консистентности стиля и документирование решений. Убрать ревью — значит убрать канал, через который junior-инженеры учатся паттернам кодовой базы, а senior-инженеры остаются в курсе того, что происходит за пределами их модулей.

Задача — сделать ревью быстрым и полезным одновременно.

Модель Google: один ревьюер и три одобрения

Google обрабатывает десятки тысяч code review в день через свой инструмент Critique, и 97% инженеров удовлетворены этим процессом. Три факта объясняют эту цифру.

Во-первых, более 75% ревью в Google проводятся одним ревьюером. Один человек совмещает три роли: проверка корректности, одобрение от владельца кода (code owner) и подтверждение «readability» — соответствия кода стандартам языка. Когда ревью назначается на трёх-четырёх человек, каждый из них думает, что проверит кто-то другой, и качество страдает. Один ответственный ревьюер работает внимательнее.

Во-вторых, медианный инженер в Google создаёт около 3 изменений в неделю и ревьюирует около 4. Это означает, что ревью — часть ежедневной работы каждого инженера, а не отвлечение от «настоящих» задач. Google формирует эту культуру через явное ожидание: первый комментарий на ревью должен появиться в течение рабочего дня.

В-третьих, изменения в Google маленькие. Медианный changelist затрагивает около 24 строк кода. Маленькие изменения ревьюируются быстро, ревьюер может удержать весь контекст в голове, а автору проще реагировать на комментарии.

Размер PR: единственная метрика, которая предсказывает качество ревью

Исследования и индустриальные данные сходятся в одном: чем больше pull request, тем хуже качество ревью. На diff в 150 строк ревьюер находит реальные проблемы. На diff в 1000 строк — ставит approve и пишет «LGTM», потому что разобраться в таком объёме за разумное время невозможно.

Graphite — инструмент для stacked pull requests — собрал данные по своим пользователям: команды, перешедшие на stacked PR, отправляют на 36% больше изменений при 17% уменьшении медианного размера PR. Semgrep после внедрения Graphite увеличил объём отправленного кода на 65% на инженера. Shopify зафиксировал рост на 33% мержей на разработчика.

Stacked PR — это подход, при котором большая задача разбивается на цепочку зависимых pull request’ов: первый PR добавляет модель данных, второй — API-эндпоинт, третий — UI. Каждый PR ревьюируется и мержится отдельно, и ревьюер в каждый момент видит изменение, которое помещается на один экран. Meta и Google давно используют аналогичный подход через stacked diffs в Phabricator и Critique соответственно.

Что автоматизировать, а что оставить людям

Автоматизация убирает из ревью механическую работу — и освобождает внимание ревьюера для вещей, которые машина пока делает плохо.

Линтеры и форматтеры (ESLint, Prettier, Black, gofmt) должны запускаться в CI до ревью. Если PR приходит с нарушениями стиля, ревьюер тратит когнитивные ресурсы на форматирование вместо логики — а когнитивная нагрузка ревьюера и без того высока. Настройте pre-commit hooks или CI-чеки, которые блокируют мерж при нарушении стиля — и эта категория комментариев исчезнет из ревью навсегда.

CODEOWNERS в GitHub назначает ревьюеров автоматически, основываясь на том, какие файлы затронуты. Это устраняет паузу «кому назначить ревью?» и направляет изменение к человеку, который лучше всех знает этот участок кода.

AI-инструменты для code review (GitHub Copilot code review, CodeRabbit, Sourcery) могут находить типичные проблемы: неиспользуемые переменные, потенциальные null pointer exceptions, отсутствие обработки ошибок. По данным Stack Overflow 2025, 18% разработчиков используют Cursor, и AI-ассистенты в code review набирают популярность. Но у них есть характерная слабость: на больших diff’ах AI генерирует шум, а не сигнал.

Людям оставьте архитектурные вопросы, оценку именования и абстракций, проверку бизнес-логики и обсуждение альтернативных подходов. Фиксируйте принятые архитектурные решения через docs-as-code, чтобы они не терялись в комментариях к PR. Это те вещи, которые требуют понимания контекста проекта, целей команды и компромиссов, о которых AI пока не знает.

Рекомендации для вашей команды

Установите SLA на первый ответ — 4 рабочих часа. Не на approve, а на первый комментарий: вопрос, замечание, «выглядит хорошо, мержи». Это снимает тревогу ожидания у автора и даёт ревьюеру гибкость — можно быстро глянуть, попросить контекст и вернуться позже.

Ограничьте размер PR. Договоритесь в команде о максимуме — 300 строк изменённого кода, например. Если задача требует больше — разбивайте на stacked PR или последовательные PR с чёткими границами. Используйте Graphite, если ваш проект на GitHub, или встроенные механизмы stacked diffs, если вы на Gerrit или Phabricator.

Выделите время на ревью в расписании. Два слота по 30 минут в день — утром и после обеда — достаточно, чтобы не копились завалы и не приходилось прерываться посреди своей работы.

Автоматизируйте всё, что можно автоматизировать: стиль, типы, покрытие тестами, CODEOWNERS. Чем меньше механической работы в ревью, тем выше плотность полезных комментариев и тем приятнее этот процесс для обеих сторон.