Размер PR задаёт латентность ревью и детект разом

Прия в одно утро открывает два PR. Первый — фикс бага на 40 строк; Сэм подхватывает его между встречами, читает каждую строку, оставляет один настоящий вопрос, апрувит — готово до обеда. Второй — «рефакторинг + новый export-пайплайн» на 1600 строк, который она девять дней полировала на ветке. Он висит. Ни у кого нет свободного блока в 90 минут, так что он два дня ждёт ревьюера, потом получает одиннадцать комментариев — десять про нейминг, один про строку лога — и LGTM. Логика батчинга в пайплайне, настоящий риск, так и не обсуждается. Через три недели он тихо теряет каждое событие, пришедшее во время ретрая. Малый PR получил больше настоящего ревью, чем большой, и в десять раз быстрее.

Детект пиков в узкой полосе, потом обрыв

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

Неинтуитивное следствие: большой PR не зарабатывает пропорционально больше проверки за то, что он большой. Внимание не масштабируется с размером диффа; когнитивный бюджет человека зафиксирован на нескольких сотнях строк. Так что PR на 1600 строк получает менее эффективное ревью, чем на 160, а не более. Это и есть механизм штампа без чтения — ревьюер комментирует то, что локально видно (имя, строку лога), и апрувит, потому что только это влезает в бюджет. Настоящие дефекты дизайна прячутся в гигантских диффах именно потому, что гигантские диффы — те, которые никто не может прочитать целиком.

Латентность — это очередь, и большие PR голодают в её начале

PR на ревью — это заблокированная работа: автор не может смёржить, часто не может чисто начать следующее, и каждый час ожидания — это замороженный прогресс. Доминирующая часть оборота обычно не само ревью; это латентность подхвата, промежуток до того, как кто-то посмотрит. А подхват — это очередь, движимая размером задачи. Данные Google — чистейшая иллюстрация: разработчики ждут в среднем меньше часа для малых изменений, но около пяти часов для очень больших, потому что ревьюер найдёт пятиминутное окно для малого CL между встречами, а изменению на 1500 строк нужен непрерывный блок, который почти не появляется в загруженном календаре. Большой PR не просто ревьюится хуже — он дольше стоит в очереди, потому что его время обслуживания превышает промежутки в чьём-либо дне.

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

Разбей партию: стекинг, а не big-bang

Возражение реально: некоторые изменения действительно большие. Миграция плюс использующий её код, рефакторинг, затрагивающий сорок мест вызова — не всегда можно выкатить 200 строк. Ответ — разбить партию, а не сдаться и смёржить монолит. Разрежьте по швам, каждый из которых самостоятелен и независимо улучшает здоровье кода: сначала приземлите чистый рефакторинг (сохраняющий поведение, легко проверяемый), затем фичу поверх чистой базы, затем обвязку. Stacked diffs делают это практичным — цепочка малых зависимых PR, каждый ревьюится в своём читаемом окне, так что ревьюер никогда не сталкивается более чем с несколькими сотнями строк за раз, хотя всё изменение большое.

Это тот же принцип размера партии из lean, что движет trunk-based разработкой: малые партии вскрывают проблемы рано и дёшево; большие прячут их, пока они не сдетонируют вместе. PR на 1600 строк — одна огромная партия, которую нельзя частично заапрувить: всё-или-ничего, а «всё» означает штамп без чтения. Четыре PR по 400 строк — четыре малые партии, каждая получает настоящее внимание, быстрый подхват и возможность быть отклонённой или починенной в изоляции. Автор платит небольшую цену декомпозиции заранее; команда избегает гораздо большей цены — нечитаемого диффа, протаскивающего непроверенный дефект.