Заревьювить — что это, как работает code review и проверка PR

Что такое code review

Code review — это систематическая проверка кода коллегами перед его интеграцией. В контексте Git это означает: разработчик создаёт pull request с изменениями, назначает ревьюверов, и те изучают diff, оставляют комментарии и выносят вердикт. Ревьювер может запросить изменения (Request Changes), одобрить PR (Approve) или оставить общий комментарий.

Code review преследует пять целей: повышение качества кода (поиск дефектов до попадания в production), распространение знаний (ревьювер узнаёт о новых подходах, автор получает обратную связь), соблюдение стандартов (проверка соответствия code style и архитектурным решениям), снижение bus factor (код знает не один разработчик) и построение культуры ответственности (автор пишет аккуратнее, зная, что код будут проверять).

Противоположность code review — blind commit: разработчик пушит изменения в общую ветку без ревью. Такой подход допустим только в однопользовательских проектах или для срочных hotfix с последующим ревью постфактум. В профессиональной командной разработке code review — обязательный этап для любого изменения, включая правки документации и конфигурации.

Что проверять в code review

Code review должен быть систематическим, а не хаотичным. Опытные ревьюверы проверяют код в определённом порядке: сначала архитектура и логика, потом тесты, затем безопасность и производительность, и только в конце — стиль и naming. Такой порядок гарантирует, что критические проблемы будут замечены до того, как ревьювер устанет.

Архитектура и логика: решает ли код задачу, нет ли избыточных абстракций, соблюдены ли принципы SOLID и DRY. Сложный код, который трудно понять с первого прочтения — сигнал, что требуется рефакторинг. Ревьювер должен убедиться, что код делает именно то, что указано в задаче, и не имеет побочных эффектов за пределами своей ответственности.

Тесты: покрывают ли новые тесты все сценарии — позитивные, негативные, граничные случаи. Проходят ли существующие тесты после изменений. Нет ли flaky-тестов, которые падают нестабильно. Безопасность: отсутствие SQL-инъекций, XSS, утечек чувствительных данных через логи или ответы API. Производительность: эффективность алгоритмов, избыточные запросы к БД, утечки ресурсов.

• Архитектура — корректность решения, соблюдение SOLID, отсутствие over-engineering.
• Логика — обработка всех сценариев, включая ошибки и граничные случаи.
• Тесты — покрытие новых изменений, отсутствие сломанных старых тестов.
• Безопасность — инъекции, XSS, CSRF, утечки данных через логи.
• Производительность — сложность алгоритмов, N+1 запросы, утечки памяти.

Размер ревью: почему 400 строк — максимум

Ограничение размера PR — наиболее важная метрика эффективности code review. Исследование Cisco (2015) и последующие эксперименты SmartBear и Google показали: при объёме ревью более 400 строк резко падает способность ревьювера находить дефекты. Если PR превышает 400 строк, ошибки в нём выявляются с вероятностью не выше случайной.

Оптимальный размер: 200-400 строк на один PR. Такой объём ревьювер может проверить за 30-60 минут, сохраняя концентрацию. Google рекомендует не более 200 строк за один раунд ревью с полной концентрацией. Если изменения больше — задачу нужно декомпозировать на несколько последовательных PR, каждый из которых вносит логически завершённое изменение.

Время ревью: в течение 24 часов с момента создания PR. Если ревью затягивается на несколько дней, контекст задачи теряется, и автору приходится тратить время на восстановление контекста при ответе на комментарии. Команды с высокой культурой code review устанавливают SLA на ревью: например, 4 часа для критичных изменений и 24 часа для обычных.

Как правильно писать комментарии к ревью

Тон комментариев — критически важен для эффективности code review. Комментарий «Это неверно» вызывает защитную реакцию и не даёт автору полезной информации. Лучшая формулировка — вопрос-предложение: «Что думаешь о таком подходе?», «Здесь может быть NPE, если user == nil. Может, добавить guard?». Вопросы меньше давят и стимулируют обсуждение.

Структура хорошего комментария включает три части: что не так, почему это проблема и как исправить. Пример: «В этом цикле используется O(n²) из-за вложенного contains, что может тормозить при 10k+ записей. Попробуй заменить на Set для O(1) поиска». Такая формулировка одновременно указывает проблему, объясняет её важность и предлагает решение — автору не нужно додумывать.

GitHub и GitLab поддерживают suggestions — встроенные предложения изменений кода. Ревьювер может написать: «```suggestion Отфильтровать пустые строки перед обработкой```» — и автор применит изменение одним кликом. This ускоряет мелкие правки и снижает количество раундов ревью. Для крупных правок лучше написать общий комментарий, чем встраивать большие блоки в suggestion.

# Template for good code review comment

# BAD: "This code is wrong"
# GOOD: "We may lose data on empty response.
#         If response.data == nil, the guard returns nil,
#         and user sees empty screen without error.
#         Maybe add a fallback error message?"

# GitHub suggestion syntax:
# ```suggestion
# let result = try? parse(response, fallback: .defaultValue)
# ```

Workflow code review в команде

Эффективный workflow ревью строится на четырех этапах. Первый — автор готовит PR: пишет понятное название (например, «feat: add password reset screen»), добавляет описание изменений, ссылки на задачу в трекере и инструкции по тестированию. Второй — автор назначает ревьюверов через auto-assign (на основе CODEOWNERS) или вручную.

Третий этап — ревьювер проверяет код и оставляет комментарии. Четвёртый — автор вносит правки, отвечает на комментарии и запрашивает повторное ревью. Цикл повторяется до получения аппрува. После аппрува автор выполняет merge (или merge выполняет бот). Автоматизация через Mergify или GitHub Auto-merge ускоряет финальный этап.

Важный элемент workflow — stale PR management. Если PR висит без ревью больше 3 дней, процесс блокируется. Решения: ротация ревьюверов (если назначенный недоступен), уведомления через Slack/Teams, лимит времени для ревью (SLA). В некоторых командах PR без ревью более 7 дней автоматически закрывается, и автор создаёт новый после синхронизации с main.

• Создание PR — понятное название, описание, ссылки на задачу, скриншоты при UI-изменениях.
• Назначение — auto-assign через CODEOWNERS или ручной выбор 1-2 ревьюверов.
• Ревью — проверка в порядке: архитектура → логика → тесты → безопасность → стиль.
• Правки — автор отвечает на все комментарии, исправляет blocking issues, запрашивает re-review.
• Merge — после аппрува и зелёного CI автор или бот выполняет слияние.

Типичные ошибки code review

Первая ошибка — поверхностное ревью. Ревьювер бегло просматривает diff, не вникая в логику, и нажимает Approve. Причины: большой PR, deadline, усталость. Последствия: баги попадают в production. Решение: если нет времени на качественное ревью — честно напишите «Не могу проверить сегодня, перенесите на завтра» вместо формального аппрува.

Вторая ошибка — чрезмерная критика (nitpicking). Ревьювер оставляет десятки комментариев по стилю форматирования, именованию переменных, тривиальным деталям. Это демотивирует автора и затягивает ревью. Решение: StyleGuide и линтеры должны проверять стиль автоматически. Человек в ревью проверяет логику, архитектуру и безопасность.

Третья ошибка — ревью без вопросов. Если ревьювер ставит только Request Changes и Approve, но не задаёт вопросов, он упускает возможность научиться чему-то новому. Лучший индикатор здоровья code review — наличие обсуждений, в которых обе стороны узнают новое. Если ревью — это монолог одного из участников, процесс сломан.

• Поверхностное ревью — Approve без погружения. Решение: не ревьюить, если нет времени.
• Nitpicking — критика стиля, который проверяется линтером. Решение: автоматизировать style checks.
• Личное восприятие — «я бы написал иначе». Решение: код должен быть рабочим, а не нравиться ревьюверу.
• Затягивание — ревью дольше 24 часов. Решение: SLA на ревью, эскалация при нарушении.
• Игнорирование контекста — ревью кода без понимания задачи. Решение: читать описание PR перед diff.