Как упростить кодревью Делюсь проверенными на личном опыте спо | Заметки Андрея Романова

Как упростить кодревью
Делюсь проверенными на личном опыте способами упростить ревью вашего кода и в целом повысить культуру кодревью в компании.

Размер пулреквестов — 80% успеха

Чем меньше пулреквесты — тем лучше. Большие PR демотивируют ревьюеров и снижают качество ревью, потому что сложно удерживать объём изменений в голове.

Если получается большой пулреквест, возможно вы смешали в нём правки в разных частях системы, требуемые для решения исходной задачи. Такие правки обычно можно разбить на отдельные PR: например, отделить новые UI-компоненты от реализации страницы с их использованием.

Ещё один случай больших PR — рефакторинги. Обычно их можно разделить на две части:
1. Содержательные изменения в какой-то части системы
2. Шаблонное обновление остального кода

Отделите первое от второго, и вы сэкономите время и силы ревьюеров, которым не очень важен бойлерплейт.

В завершение про размер пулреквестов: не поддавайтесь соблазну докинуть новую функциональность в уже открытые PR. Новая функциональность — новый пулреквест. Это опять же про самодостаточные изменения и внимание ревьюеров, которое не бесконечно.

Описание изменений

Ревьюерам сильно поможет внятное описание ваших изменений. Какую задачу вы решали, почему решили её именно так, на что стоит обратить внимание.

Не ленитесь описать это прямо в PR, не все открывают прилинкованные задачи, и в них может не хватать контекста.

В идеале описание нужно сопроводить ссылкой на тестовый стенд, где изменения можно оценить вживую. Если стенда нет, позаботьтесь о том, чтобы проект было легко запустить локально, и сопроводите описание скриншотами конечных изменений (актуально для фронтендеров).

Если пулреквест содержит неочевидные решения или хаки, от которых не избавиться, заранее сопроводите их комментариями прямо в коде — для ревьюеров и для будущих поколений, которые будут читать этот код.

Не стесняйтесь сопроводить PR собственными комментариями на отдельных участках кода, чтобы:
— указать порядок чтения;
— прояснить мотивацию к конкретным изменениям;
— явно обратить внимание на сложные места;
— явно запросить обратную связь, если сомневаетесь в своём коде.

Ревью собственных пулреквестов

Прежде чем запрашивать ревью у других разработчиков, просмотрите свои изменения, будто кто-то другой запросил у вас ревью. Так вы сэкономите своё и чужое время, сразу обнаружив очевидные косяки вроде опечаток или забытого кода для отладки.

Уведомления о ревью

Чтобы вам и ревьюерам не приходилось вручную следить за запросами ревью, комментариями, апрувами и прочим, настройте уведомления о них в рабочем мессенджере. Например, я использую интеграцию GitHub и Slack.

Явное обозначение намерений в комментариях

У вас будет больше взаимопонимания, если ревьюер явно обозначит, какие замечания считает критичными, а какие можно проигнорировать.

Conventional Comments — хороший пример готовых соглашений для обозначения намерений.