Процесс и workflow

Вы научитесь настраивать три параметра, от которых зависит скорость ревью больше, чем от чего-либо ещё: размер PR, правило назначения ревьюера и срок ответа. И увидите, почему шаблон описания PR — не бюрократия, а инструмент, экономящий раунды.

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

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

Практический предел — около 400 строк содержательных изменений, не считая сгенерированного кода, файлов блокировки и переносов. Это не догма, а точка, после которой ценность ревью резко падает.

Работающие способы разбить большой PR:

Формулировка для ревьюера, у которого нет власти отклонить: «PR слишком велик, чтобы я мог за него отвечать. Могу посмотреть слой API, но за остальное поручиться не смогу». Это честно и обычно приводит к разбиению.

Проверьте себя. Постройте распределение размеров PR за последние три месяца. Какая доля больше 400 строк?

Частая ошибка. Требовать разбиения задним числом, когда PR уже написан. Разбивать надо на этапе планирования — то есть договорённость о размере должна существовать до работы.

«Кто-нибудь посмотрите» — не назначение. PR без конкретного адресата ждёт дольше всех: каждый видит его и думает, что посмотрит другой.

Три работающие схемы:

Владельцы кода. Файл CODEOWNERS сопоставляет пути и людей, назначение происходит автоматически.

Плюс: гарантия, что критичный код смотрит компетентный человек. Минус: концентрация знаний — если billing всегда смотрит Alice, никто больше в нём не разбирается. Лечится дополнительным случайным ревьюером сверх владельца.

Дежурство. Один человек в день отвечает за все входящие PR. Плюс: предсказуемость, никто не ждёт. Минус: дежурный не всегда компетентен в конкретной области — поэтому дежурство обычно комбинируют с владельцами для чувствительных путей.

Случайное назначение из пула. Хорошо распределяет знания, плохо работает без выравнивания нагрузки: без него всё уходит к тем, кто быстрее отвечает.

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

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

Частая ошибка. Требовать двух одобрений на все PR. Это удваивает время ожидания ради выигрыша, который измеряется единицами найденных проблем.

Ценность SLA не в скорости, а в предсказуемости. Автор, знающий, что ответ придёт в течение четырёх часов, спокойно берётся за следующую задачу. Автор, не знающий ничего, проверяет PR каждые двадцать минут и не начинает новое.

Разумные значения:

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

Что нужно, чтобы SLA соблюдался:

Проверьте себя. Измерьте медианное время до первого ответа за месяц. И отдельно — время повторного ответа после правок.

Частая ошибка. Вводить SLA без измерения. Необъявленный срок и неизмеряемый срок одинаково не работают.

Шаблон описания кажется формальностью, пока не посчитать, сколько раундов уходит на выяснение контекста.

Полезное описание отвечает на четыре вопроса и занимает пять строк:

Четвёртый раздел ценнее остальных и почти никогда не заполняется. Автор знает, где его код слабее всего, — и указание на это место экономит ревьюеру полчаса поиска и повышает шанс, что проблему найдут.

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

Разумное правило: PR без описания не берут в ревью. Не как наказание — просто без контекста ревьюер проверяет код, а не решение.

Проверьте себя. Откройте пять последних PR. По скольким понятно, зачем они, без чтения диффа?

Частая ошибка. Шаблон на страницу. Чем он длиннее, тем формальнее заполняется.

Список должен быть коротким, явным и одинаковым для всех. Всё, что в него не входит, мержу не мешает.

Разумный минимум: CI зелёный; одно одобрение (два — для платежей, безопасности, миграций); нет незакрытых blocker; ветка обновлена относительно основной.

Чего в списке быть не должно: закрытых nit (они не блокируют по определению), одобрения тимлида (иначе решение перестаёт быть техническим), «всех ревьюеров» — достаточно требуемых.

Отдельно нужен явный механизм обхода для инцидентов: метка с обязательным обоснованием и последующим разбором. Без него в первый же серьёзный инцидент правила просто нарушат, и после этого они перестанут работать вообще.

Проверьте себя. Совпадает ли список обязательных проверок в настройках репозитория с тем, что команда считает обязательным?

Частая ошибка. Требовать закрытия всех комментариев для мержа. Это делает nit блокирующим вопреки его смыслу.

Команда из девяти человек. Медианное время до мержа — четыре дня, участились горячие исправления. На разборе собрали цифры:

Тимлид предложил документ «Регламент code review» на четыре страницы: обязательное описание, чек-лист из двенадцати пунктов, требование ревьюить в день поступления, ограничение PR тремястами строк, три обязательных одобрения для критичных модулей.

Что видит опытный участник. Диагноз по цифрам верный, лечение усугубит проблему.

Три обязательных одобрения при том, что 58 % ревью уже делает один человек, увеличат ожидание, а не качество. Узкое место — не количество проверяющих, а их доступность.

Требование «ревьюить в день поступления» без выделенных окон и без измерения — пожелание. Оно уже фактически существует и не выполняется; повторение его в документе ничего не изменит.

Чек-лист из двенадцати пунктов будет проставляться не читая. Ключевой показатель — 61 % PR без описания — говорит, что проблема не в отсутствии формы, а в том, что заполнение не даёт автору выгоды.

И самое главное: медиана 680 строк не лечится строчкой в регламенте. Разбивать PR надо на этапе планирования задачи, а это вопрос декомпозиции в бэклоге, а не правил ревью.

Что в цифрах пропущено: повторный ответ (22 часа) медленнее первого (19 часов). При 3.4 раундах это и даёт четыре дня. Самый дешёвый выигрыш — здесь.

Комментарии к предложению:

Чем закончилось. Регламент заменили на изменения, которые видно в интерфейсе:

Через два месяца: медиана размера PR — 240 строк, время до первого ответа — 3 часа, повторного — 1 час, раундов — 2.1, время до мержа — 6 часов вместо четырёх дней. Доля ревью у тимлида упала до 22 %.

Самое интересное: качество ревью выросло, хотя обязательных одобрений стало меньше. Причина в размере PR — на 240 строках ревьюер действительно читает всё.

Как это настраивается технически — Инструменты и интеграции. Что и как измерять — Метрики процесса. Особенности при распределённой команде — Remote и асинхронность.