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

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

В-третьих, изменения в 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. Чем меньше механической работы в ревью, тем выше плотность полезных комментариев и тем приятнее процесс для обеих сторон.