Делюсь проверенными на личном опыте способами упростить ревью вашего кода и в целом повысить культуру кодревью в компании.
📏 Размер пулреквестов — 80% успеха
Чем меньше пулреквесты — тем лучше. Большие PR демотивируют ревьюеров и снижают качество ревью, потому что сложно удерживать объём изменений в голове.
Если получается большой пулреквест, возможно вы смешали в нём правки в разных частях системы, требуемые для решения исходной задачи. Такие правки обычно можно разбить на отдельные PR: например, отделить новые UI-компоненты от реализации страницы с их использованием.
Ещё один случай больших PR — рефакторинги. Обычно их можно разделить на две части:
- Содержательные изменения в какой-то части системы
- Шаблонное обновление остального кода
Отделите первое от второго, и вы сэкономите время и силы ревьюеров, которым не очень важен бойлерплейт.
В завершение про размер пулреквестов: не поддавайтесь соблазну докинуть новую функциональность в уже открытые PR. Новая функциональность — новый пулреквест. Это опять же про самодостаточные изменения и внимание ревьюеров, которое не бесконечно.
📝 Описание изменений
Ревьюерам сильно поможет внятное описание ваших изменений. Какую задачу вы решали, почему решили её именно так, на что стоит обратить внимание.
Не ленитесь описать это прямо в PR, не все открывают прилинкованные задачи, и в них может не хватать контекста.
В идеале описание нужно сопроводить ссылкой на тестовый стенд, где изменения можно оценить вживую. Если стенда нет, позаботьтесь о том, чтобы проект было легко запустить локально, и сопроводите описание скриншотами конечных изменений (актуально для фронтендеров).
Если пулреквест содержит неочевидные решения или хаки, от которых не избавиться, заранее сопроводите их комментариями прямо в коде — для ревьюеров и для будущих поколений, которые будут читать этот код.
Не стесняйтесь сопроводить PR собственными комментариями на отдельных участках кода, чтобы:
- указать порядок чтения;
- прояснить мотивацию к конкретным изменениям;
- явно обратить внимание на сложные места;
- явно запросить обратную связь, если сомневаетесь в своём коде.
🕵️ Ревью собственных пулреквестов
Прежде чем запрашивать ревью у других разработчиков, просмотрите свои изменения, будто кто-то другой запросил у вас ревью. Так вы сэкономите своё и чужое время, сразу обнаружив очевидные косяки вроде опечаток или забытого кода для отладки.
🔔 Уведомления о ревью
Чтобы вам и ревьюерам не приходилось вручную следить за запросами ревью, комментариями, апрувами и прочим, настройте уведомления о них в рабочем мессенджере. Например, я использую интеграцию GitHub и Slack.
🤝 Явное обозначение намерений в комментариях
У вас будет больше взаимопонимания, если ревьюер явно обозначит, какие замечания считает критичными, а какие можно проигнорировать.
Conventional Comments — хороший пример готовых соглашений для обозначения намерений.