Размер PR измеряется в изменённых строках кода и количестве затронутых файлов. Маленькие PR проще и быстрее ревьюить, они реже содержат ошибки и легче откатываются в случае проблем. Команды, которые системно следят за размером PR, как правило, демонстрируют более высокое качество кода и более короткий lead time.
Количество изменённых строк в одном PR. Оптимально: 200–400 строк.
УСИЛИВАЕТСЯ: Атомарные изменения (правка API + всех потребителей) часто порождают гигантские PR. Без использования Stacked PRs (как в Graphite) такие изменения становятся практически нечитаемыми, что резко снижает качество проверки.
УСИЛИВАЕТСЯ: Возникает порочный круг — разработчики, зная о задержках из-за часовых поясов, стараются впихнуть больше правок в один PR, чтобы сократить число раундов ревью. Это делает PR ещё больше, ревью — ещё дольше, а задержки — ещё критичнее.
Давление на батчинг возрастает с масштабом.
+100 строк → +25 мин ревью. ~50-строчные PR сливаются на 40% быстрее.
>1,000 строк → на 70% ниже обнаружение дефектов.
Крупные PR дольше на каждой стадии.
Крупные изменения чаще конфликтуют с PR в очереди.
Необнаруженные дефекты доходят до прода. Предупреждения о размере → на 35% меньше дефектов.
Большие PR дольше писать, ревьюить и мерджить. 200-строчный PR = 1 день. 2000-строчный PR = несколько дней.
Разработчики группируют изменения в крупные PR, чтобы реже сталкиваться с нестабильными тестами.
Медленный пайплайн стимулирует группировку изменений в меньшее число крупных PR.
Медленное ревью → меньше и крупнее PR, чтобы сократить число раундов.
Дорогие прогоны стимулируют батчинг.
Частые деплои → не нужно батчить изменения.
Разработчики группируют межкомандные изменения, чтобы минимизировать раунды координации. Обновление общего API + 15 потребителей в одном PR.
Атомарные изменения общих библиотек + всех потребителей создают огромные PR.
Разработчики собирают больше изменений в один PR, чтобы минимизировать дорогостоящие циклы через часовые пояса.
154% больше PR'ы от AI-батчинга.