Проверка кода коллегой ловит ошибки до того, как их найдут пользователи, и распространяет знания о проекте: после нескольких месяцев регулярных ревью в команде не остаётся модулей, которые понимает один человек. Плохо организованное ревью даёт обратный эффект — тормозит работу, превращается в спор о запятых и портит отношения. Ниже то, как мы выстраиваем этот процесс на своих проектах и что советуем командам заказчиков.
Зачем это нужно, кроме поиска ошибок
Поиск дефектов — самая очевидная, но не единственная задача ревью. Не менее важно, что второй человек видит контекст изменений: он узнаёт, как устроен соседний модуль, замечает дублирование с тем, что уже написано, и может сказать, что похожая задача решалась в проекте полгода назад другим способом.
Третий эффект — общая планка. Когда код читают, его пишут аккуратнее: меньше временных решений, оставленных «на потом», меньше закомментированных кусков и неочевидных сокращений в именах. Это не требует отдельных усилий и работает само, если проверка идёт регулярно, а не перед релизом раз в квартал.
Правила для автора
Больше половины качества ревью обеспечивает тот, кто отправляет изменения, а не тот, кто их читает.
- Небольшие изменения: ориентир — до 200-400 строк. Крупные правки читают по диагонали, и проверка становится формальной.
- Понятное описание: что менялось, почему и что проверить в первую очередь. Ссылка на задачу не заменяет пары предложений.
- Отдельно переформатирование, отдельно смысловые правки. Смешанная правка на тысячу строк, где девятьсот — перенос отступов, непроверяема.
- Самопроверка перед отправкой: прочитать собственный диф целиком. Половина замечаний снимается на этом шаге.
- Приложенный результат: скриншот, лог, запрос и ответ. Проверяющему не приходится разворачивать ветку, чтобы понять, что получилось.
Отдельная привычка — не отправлять на проверку то, что заведомо не готово. Если правка нужна ради обсуждения подхода, это стоит написать прямо в описании: тогда читают архитектуру, а не имена переменных.
Правила для проверяющего
Задача читающего — не показать, как он написал бы сам, а убедиться, что изменение решает задачу и не ломает соседнее.
| Что делать | Чего избегать |
|---|---|
| Смотреть на логику и крайние случаи | Спорить о стиле, который проверяет линтер |
| Задавать вопросы: «что будет при пустом ответе?» | Требовать переписать «как я бы сделал» |
| Отмечать удачные решения | Оставлять только критику |
| Проверять в течение рабочего дня | Держать правку неделю без ответа |
| Различать «нужно исправить» и «можно подумать» | Смешивать важное с придирками в одном списке |
| Предлагать вариант, если требуете изменений | Ограничиваться формулировкой «плохо» |
Разделение замечаний по весу экономит больше всего времени. Когда десять комментариев идут вперемешку, автор либо исправляет всё подряд, включая необязательное, либо спорит по каждому. Пометка вида «блокирует» и «на усмотрение» снимает этот вопрос за секунду.
На что смотреть в первую очередь
- Правильность логики и обработка ошибок: что происходит при пустом, слишком большом и неожиданном значении.
- Безопасность: проверка ввода, права доступа, работа с чужими данными и внешними запросами.
- Производительность: запросы в цикле, выборки без ограничений, тяжёлые операции в обработчике страницы.
- Читаемость: имена, разбиение на функции, отсутствие скрытых зависимостей.
- Наличие тестов на важное поведение и на исправленную ошибку.
- Совместимость: миграции, изменения в интерфейсах, влияние на другие модули и на уже опубликованные данные.
Порядок здесь не случаен. Замечание о неудачном имени переменной всегда легче сформулировать, чем вопрос об обработке ошибок, поэтому при беглом чтении список получается вывернутым наизнанку: десять правок по стилю и ни одного вопроса о том, что случится при недоступности внешнего сервиса.
Что автоматизировать
Форматирование, стиль, порядок импортов, простые проверки на типичные ошибки — задача инструментов. Линтер и автоформатирование настраиваются один раз и снимают целый класс споров: правило перестаёт быть чьим-то мнением и становится настройкой проекта.
Туда же уходит запуск тестов и сборки до проверки человеком. Если правка не собирается или ломает тесты, читать её рано. Человеческое внимание должно уходить на то, что машина не проверит: уместность решения в проекте, полноту обработки крайних случаев и последствия для соседних частей системы.
Сроки и как не блокировать команду
Долгое ожидание проверки — главная причина, по которой ревью в командах тихо умирает. Пока правка ждёт, ветка расходится с основной, автор переключается на другую задачу, а возвращаться к обсуждению приходится по остывшему контексту. Разумный ориентир — реакция в течение рабочего дня, даже если это ответ «посмотрю завтра утром».
Помогают простые договорённости: у каждой правки есть назначенный проверяющий, а не «кто-нибудь из команды»; проверка идёт в начале дня, до собственных задач; крупные изменения обсуждаются голосом до написания кода, а не после. Последнее особенно полезно на архитектурных задачах, где спор в комментариях к готовой правке означает переделку недели работы.
Ревью в проекте с внешним подрядчиком
Когда над кодом работают несколько сторон, ревью становится ещё и способом сохранить проект понятным для заказчика. Мы договариваемся на старте: проверку проходят все изменения, включая срочные; в описании правки указывается задача из трекера; специалист на стороне клиента получает доступ к обсуждениям, даже если сам код не читает.
Это снимает типичную проблему передачи проекта, когда через год выясняется, что решения принимались устно и восстановить их логику не по чему. История ревью — это готовая документация по спорным местам: видно, какой вариант рассматривали, почему выбрали другой и какие ограничения были известны на тот момент.
Тон обсуждения
Замечание относится к коду, а не к автору. Формулировка «здесь потеряется ошибка при пустом ответе» работает, «ты опять не подумал» — нет. Разница не в вежливости ради вежливости: первая формулировка содержит проверяемое утверждение, на которое можно ответить по существу, вторая — оценку человека, на которую отвечают защитой.
В командах, где это правило соблюдается, ревью проходит быстрее и находит больше: люди спокойнее отправляют на проверку сырые решения и честнее пишут о сомнениях. Отдельно стоит договориться, что спорные вопросы после двух кругов переписки переносятся в разговор — текстом такие обсуждения затягиваются на дни.
Приглашение
Если команду нужно усилить людьми, которые придут с готовыми практиками ревью и тестирования, а не будут выстраивать их с нуля, мы подключаемся к проекту в удобном формате. Посмотрите, как это устроено, на странице выделенная команда разработчиков.
