Терпеть не могу код ревью (3/4) - Регламент

Мой первый PR (pull/merge request - запрос на внесение изменения в код проекта) в рамках нашего нового процесса провисел несколько суток и задержал релиз. Дискуссия под моим кодом с каждым днем только увеличивалась: коллеги продолжали спорить над тем, что уже было исправлено, и начинали новые ветки комментариев под теми частями, за которые не успели зацепиться ранее.

Чтобы не повторять такой опыт, мы договорились о регламенте ревью, который установил рамки в этом процессе:
- Все, что не относится к целям ревью (из предыдущего поста) - не является предметом ревью.
- Ответственный за PR - его автор. Он следит за тем, чтобы ревьюверы не забыли прожать галочку, когда код можно вливать в основную ветку.
- Разработчик вправе не исправлять каждое замечание.
- Однако, есть критичные замечания, которые обязательны к исправлению. Такие ревьювер должен выделять, чтобы они не затерялись среди других комментариев.
- Концептуальные вопросы выносятся на обсуждение в общий чат и позднее закрепляются в стайл гайде (та самая страничка в нашем confluence/wiki), куда можно ссылаться в следующий раз.
- Ревью подлежит только новая функциональность, но не исправления багов.
- Критикуя, оставляй предложения.
- Ревью не только для замечаний: узнали что-то новое из PR своего коллеги, или увидели, что качество кода возросло - отметьте это и похвалите.

После этого мы договорились об ограничениях в сроках проверки PR. Это было нужно, чтобы не затягивать ревью на несколько дней. Помимо этого, определили минимальное условие, необходимое для вливания кода в основную ветку:
- PR “живет” всего 24 часа. Это означает, что у ревьюверов есть только сутки на то, чтобы дать комментарии, а у разработчика - исправить замечания.
- Если за первые 4 часа никто не прокомментировал PR, то разработчик должен попросить об этом в общем чате. Это нужно, чтобы не надоедать каждые полчаса напоминаниями о проверке.
- PR может быть влит в основную ветку только после подтверждения хотя бы одного из ревьюверов.

Как итог, за сутки жизни PR можно успеть прокомментировать только основные недочеты. Огромные ветви обсуждений при регламентированных сроках стали непродуктивными. Больше никаких ревью на несколько дней, долгих дискуссий и споров под твоей работой о том, как правильно писать код, и в какой шараге учат этому лучше.

Ну а чтобы все было совсем хорошо, мы договорились избегать коротких неконструктивных комментариев по типу “Мы так не пишем, переделай”. По двум причинам:
- Само по себе такое сообщение хоть и экономит секунды жизни ревьювера, но никак не ведет к конструктивному диалогу.
- Разбор того, а как в итоге правильно писать, затягивается надолго, поэтому и есть правило “критикуя, предлагай”. Тем самым, автор PR не дожидается следующих комментариев коллеги.

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