Code review: что ловит человек, что должна тулза, и почему латентность — настоящая цена

PR на 1800 строк падает в пятницу в 17:00: новый биллинг-флоу, миграция схемы и рефакторинг — всё одним диффом. Два ревьюера оставляют четыре комментария — переименование, пропущенная точка с запятой, «нит: лучше const» — и аппрувят. Три недели спустя миграция дважды списывает деньги с когорты клиентов, потому что путь ретрая не был идемпотентным. Никто не увидел. Дифф был слишком велик, чтобы его реально прочесть, так что ревьюеры отревьюили то, что легко увидеть: мелочь. Настоящий изъян сидел в дизайне, а дизайн — ровно то, что гигантский LGTM-нутый PR и прячет.

Ревью ловит то, чего не может тулза

Дефицитное внимание сеньора-ревьюера должно идти на то, что машина судить не может: правильный ли это дизайн, делает ли он то, что задумывал тикет, поймёт ли это следующий инженер, корректен ли путь ошибки, не открывает ли он дыру в безопасности. Собственный стандарт Google ставит дизайн первым — «самое важное, что нужно покрыть в ревью», — потому что дизайн-решения накапливаются и дорого откатываются позже, тогда как неуместная скобка не стоит ничего.

Всё, что тулза может решить детерминированно, не должно никогда доходить до человека. Форматирование, порядок импортов, конвенции именования, lint-правила, неиспользуемые переменные — гоняй форматтер и линтер в CI и сделай их блокирующими. В тот момент, когда человек печатает «нит: пробелы», ты потратил самый дорогой ресурс ревью (суждение сеньора) на самую дешёвую возможную проблему, и научил автора, что ревью — про поверхность. Инженерная культура Google проговаривает это явно: автоматизируй принуждение стиля, чтобы стиль не доходил до ревью, потом тренируй ревьюеров тратить внимание на корректность, безопасность и архитектуру.

Латентность — цена, которую никто не меряет

Число, что значит больше всего, — не количество дефектов, а время оборота. PR — это заблокированная работа: автор не может смержить, часто не может чисто начать следующее, и каждый час простоя — это час чьего-то замороженного прогресса. Данные суровы. Анализ примерно 8 миллионов pull request’ов нашёл, что элитные команды закрывают полный цикл ревью меньше чем за 26 часов, тогда как отстающие дают PR простоять неделю до того, как ревью вообще начнётся. Самый большой кусок этого времени — не ревью, а первичный подхват, разрыв до того, как кто-то взглянет. Распределённые команды платят ещё 8–16 часов за раунд просто на разрыв часовых поясов.

У этого простоя есть цена. Тот же анализ оценил стоимость ожидания на бутылочном горлышке ревью примерно в 5,8 часа на разработчика в неделю — около $238K/год замороженного времени для команды из десяти человек, и это только ожидание, не само ревью. Вот почему DORA трактует lead time как ключевую метрику здоровья: медленное ревью напрямую деградирует пропускную способность, и команда, оптимизирующая чисто «тщательное ревью» и игнорящая латентность, меняет малый выигрыш по дефектам на большой проигрыш по потоку.

Экономика маленьких PR: детект дефектов падает с обрыва

Исследование SmartBear в Cisco — 2500 ревью на 3,2 миллиона строк кода, крупнейшее в своём роде — нашло, что сладкая точка — 200–400 строк кода на ревью. Внутри этой полосы, при ревью, растянутом не больше чем на 60–90 минут, ты получаешь около 70%+ выхода дефектов. Перевали за 400 строк, и детект резко падает; человек перестаёт читать и начинает скользить. Темп тоже важен: ревьюеры, идущие медленнее ~400 LOC/час, были выше среднего в нахождении дефектов, но за ~500 LOC/час плотность дефектов оказалась ниже среднего в 87% случаев.

Это механизм за штампом не глядя. Ревьюер перед диффом на 1800 строк не имеет бюджета удержать всё это в голове, так что делает единственное, что влезает: комментит локально видимое (имя, нит по стилю) и аппрувит. Гигантский PR не получает больше придирчивости за то, что большой — он получает меньше, потому что внимание не масштабируется с размером, а когнитивный предел ревьюера фиксирован. Большие диффы — это где прячутся реальные изъяны дизайна ровно потому, что это диффы, которые никто не может прочесть целиком.

Трейдофф сеньора: тщательность против пропускной, обмен знанием против привратничества

Каждое ревью — ставка на то, куда потратить фиксированный бюджет. Выкрути тщательность на максимум — и затормозишь поток всей команды; оптимизируй чисто под пропускную — и дефекты протекут. Ход сеньора — тратить глубину там, где риск: дизайн, миграция данных, граница auth, путь денег, — и пропускать низкорисковые диффы быстро. Стандарт Google кодифицирует это нарочито гуманным правилом: аппрувь, как только изменение определённо улучшает общее здоровье кода, даже если оно не идеально. «Не идеально» — не повод блокировать; «делает кодбазу хуже» — повод.

Вторая ось культурная: ревью как обмен знанием против ревью как привратничества. Сделанное хорошо, ревью распространяет контекст — автор узнаёт систему, ревьюер узнаёт изменение, и bus factor растёт. Сделанное как статусная игра, оно становится бикешеддингом (закон тривиальности Паркинсона: люди бесконечно спорят о цвете велосарая, потому что это единственная часть, которую они понимают) и привратничеством, где ревьюер блокирует, чтобы утвердить контроль, а не улучшить код. Признак — тред из двенадцати комментариев об именовании на PR, чей настоящий изъян дизайна уехал нетронутым. Ревью, придирающееся к мелочи и пропускающее порочный дизайн, вывернуло наизнанку всю свою цель.