Культура код-ревью: приоритеты и скорость

Можно ли обойтись без ревью ради ускорения Time-to-Market? Теоретически да, но:
1. Можно пропустить косяки
2. Код станет труднее поддерживать
3. Уход единственного разработчика может остановить проект

Альтернативы есть: парное программирование или TDR. Но они подходят не всем.

Поэтому большинство проводит код-ревью. И у большинства есть боль — «зависание» задачи на ревью.

Порефлексировал, почему кодревью затягивается, и что мы делали, чтобы это порешать.
Спойлер: мысли почерпнул в Google’s Code Review Guidelines. Далее буду ссылаться на конкретные части.

👨‍💻 Удовлетворение на этапе открытия PR

Speed of Code Reviews

Разработчик отправляет код на ревью и с чувством выполненной работы берётся за новую задачу.
Очень легко говорить «никто не ревьювит мой PR». Но кто будет ревьюить, если все кодят?

Так происходит, если написание нового кода поощряется больше, чем ревью.

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

А чтобы доводить цель до прода — код-ревью должно быть быстрым.
Задача тимлида и самих разработчиков — создать культуру, поощряющую быстрое ревью.
«Начал день — сделай ревью, прежде чем сесть кодить. На дейли обсудите спорные моменты.»

🤌 Огромные PR

Why Write Small CLs

Ревьюить атомарные PR на несколько файлов и сотню строк гораздо проще и быстрее, чем 10k строк.

- Маленькие PR ревьювят быстрее и тщательнее.
- Меньше переделывать, быстрее правки по комментам.
- Проще мержить и разрешать конфликты.
- Проще раскатывать в прод и откатывать изменения

Фича кажется «неделимой»? Попробуйте Trunk-based development: слияние в мастер не всегда рабочего кода, закрытого фича-флагами. Начало разработки с абстракций, слияние, затем написание имплементаций.

🏓 Ревью-пинг-понг

Допустим, ревью происходит быстро, но идёт уже десятая итерация.
Почему так?

1️⃣ — Новые комменты к нетронутому коду

Если ревьюер оставляет новые комментарии к неизмененному коду — это проблема. Важно за одну итерацию ревью написать все комменты, обязательные к исправлению.

Так может происходить, если ревьювер цепляется то за одно, то за другое.

Хорошее правило: «PR не должен быть идеальным — он должен улучшать код проекта на одну ступеньку».

Могут помочь статьи What to look for in a code review и Navigating in ChangeList.

2️⃣ — Комменты к исправлениям

Если комменты появляются к тому, как автор переписал код с учетом прошлых комментов — скорее всего стоит улучшить комментарии.

- Стоит объяснять, почему просишь изменений.

- Стоит разделять обязательные к исправлению пункты и опциональные.

- Стоит в явном виде писать, как предлагаешь изменить. Можно даже с частями кода.
«Критикуешь — предлагай».

How to write Review Comments

===

Итог

Мы добавили в чат бота, который каждое утро скидывает список PR для ревью. Бот приходит в личку, если ревью висит больше дня.
Но всё это не работает до тех пор, пока культура ревью не выстроена.
Как только ревью стало такой же целевой работой, как и написание кода — стало быстрее.

Это не все причины, почему задачи могут зависать на ревью.
Поделитесь опытом в комментах — какие проблемы с ревью были у вас и как решали?