Чек-лист код-ревью: что проверять в pull request
Практика3 минРедакция Innovialabs
Коротко
Хорошее ревью проверяет по порядку: решает ли код задачу, понятен ли он, есть ли тесты, нет ли дыр в безопасности и узких мест — а комментарии пишутся про код, а не про человека.
Что проверять в первую очередь
Ревью — не поиск опечаток. Его цель — убедиться, что изменение решает задачу, не ломает остальное и будет понятно следующему разработчику. Идите от важного к мелкому:
- Корректность.
- Архитектура и читаемость.
- Тесты.
- Безопасность.
- Производительность.
- Стиль — пусть его проверяют линтер и форматтер, а не люди.
Перед ревью: подготовка автора
- PR небольшой и про одну задачу. Большой PR проверяют поверхностно.
- В описании: что сделано, зачем, как проверить, ссылка на задачу.
- CI зелёный: тесты, линтер, сборка.
- Автор сам просмотрел свой diff перед отправкой.
Чек-лист ревьюера
Корректность
- Код делает то, что описано в задаче?
- Обработаны граничные случаи: пустые списки,
null, нулевые и отрицательные значения, очень длинные строки? - Что происходит при ошибке сети, базы или внешнего API?
- Нет ли гонок при параллельных запросах?
- Миграции базы обратимы и безопасны для существующих данных?
Читаемость и структура
- Понятны ли имена переменных, функций и классов без пояснений?
- Нет ли длинных функций, которые стоит разделить?
- Не дублирует ли код существующую утилиту?
- Изменение лежит в правильном слое (UI, бизнес-логика, доступ к данным)?
- Комментарии объясняют «почему», а не пересказывают «что»?
Тесты
- Есть тесты на новую логику и на исправленный баг?
- Тесты проверяют поведение, а не детали реализации?
- Упадёт ли тест, если сломать код? Тест, который проходит всегда, бесполезен.
Безопасность
- Пользовательский ввод валидируется на сервере?
- Запросы к базе параметризованы, нет склейки SQL из строк?
- Проверяются права доступа: может ли пользователь видеть и менять именно эти данные?
- Нет секретов, токенов и паролей в коде и логах?
- Новые зависимости из надёжных источников и действительно нужны?
Производительность
- Нет запросов к базе внутри цикла (проблема N+1)?
- Для больших выборок есть пагинация и нужные индексы?
- Тяжёлые операции не блокируют ответ пользователю?
Как писать комментарии
Комментарий — про код, а не про автора. Сравните:
| Плохо | Лучше |
|---|---|
| «Это неправильно» | «Здесь при пустом списке будет исключение — может, добавить проверку?» |
| «Зачем ты так сделал?» | «Помоги понять: почему выбран этот подход, а не X?» |
| «Переделай» | «Предлагаю вынести в отдельную функцию — так проще тестировать» |
Полезные привычки:
- Помечайте важность: блокер, предложение, мелочь (nit). Автор поймёт, что обязательно, а что на усмотрение.
- Объясняйте причину, а не только требование.
- Отмечайте и удачные решения — это тоже обратная связь.
- Если обсуждение затянулось на много сообщений, созвонитесь.
Как принимать комментарии
- Ревьюят код, а не вас. Замечание — не оценка квалификации.
- Если не согласны — аргументируйте, а не игнорируйте.
- Отвечайте на каждый комментарий: исправлено, обсуждаем или оставлено с причиной.
- Повторяющиеся замечания — повод добавить правило в линтер или в гайд команды.
Частые вопросы
Универсального числа нет. Ориентир — PR, который ревьюер может внимательно просмотреть за один подход. Если это невозможно, разбейте изменение на несколько последовательных PR.