Большие пул-реквесты пропускают больше багов — разбираемся, правда или миф

Интуиция ^[1] подсказывает — чем больше пул-реквест, тем выше соблазн по-быстренькому пробежаться глазами по коду и аппрувнуть изменения. Предлагаем вам вместе с нами проверить утверждение из заголовка! В статье посмотрим, к чему пришли исследователи, проанализировавшие 50К+ пул-реквестов, обсудим, какие когнитивные искажения на это влияют, и разберем, как изменилась ситуация с появлением ИИ-помощников. Поехали!

Зона оптимума

Начнем с самого масштабного из доступных исследований. Компания PropelCode проанализировала ^[2] 50 000+ пул-реквестов и выявила зависимость между количеством найденных ошибок и размером PR. И вот что выяснилось. На маленьких пул-реквестах (до 100 строк) отлавливается почти 9 из 10 ошибок, а когда размер переваливает за тысячу строк — обнаруживается лишь каждая четвертая. 

Также, согласно этому же исследованию, есть связь между размером пул-реквеста и содержательностью его обсуждения.

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

Почему мозг саботирует большие PR

Исследователи считают, что виной всему — вполне конкретные человеческие ограничения. Разработчик, открывающий дифф на тысячу строк, физически не способен удержать в голове всю картину изменений — и дело тут не в недостатке опыта ^[3], а в устройстве нашего мозга ^[4].

• Магическое число 7±2 и когнитивная перегрузка

Согласно правилу Миллера ^[5], кратковременная рабочая память ^[6] человека способна удерживать одновременно 7 ± 2 объекта, проще говоря, от 5 до 9. Когда рецензент просматривает код, он оперирует не отдельными символами, а кусочками — логическими блоками. В небольшом пул-реквесте таких блоков немного, и мозг успевает построить цельную модель изменения. Однако большие пул-реквесты человеческий мозг не всегда в состоянии полноценно переварить, что вынуждает рецензента обходиться лишь поверхностным анализом, сравнивая код со знакомыми паттернами и шаблонами.

• Ловушка масштаба

Еще коварнее феномен, который называют пренебрежением масштабом ^[7] (scope insensitivity). В случае в ревью работает это так. Наш мозг выделяет примерно одинаковый объем ментальных усилий на анализ пул-реквеста как в 100, так и в 1000 строк. Чем больше объем кода, тем меньше внимания ^[8] получит каждая из них.

• Влияние срочности

Есть и третий фактор, который редко обсуждают в контексте размера пул-реквеста, хотя он способен кратно усилить описанные выше эффекты. Пул-реквест большого объема нередко воспринимается ревьюером как срочный — коллега писал его несколько дней, а значит, сроки поджимают и надо побыстрее просмотреть, чтобы не стопорить команду. В этом случае на ревьюера с высокой долей вероятности будет давить не только непосредственно объем пул-реквеста, но и этот фактор срочности. Торопясь закрыть «висяк», разработчик может быстро пролистать дифф, поправить пару стилистических мелочей, оставить комментарий в духе «вроде норм» и аппрувнуть изменение. 

Именно такую модель поведения ^[9] и зафиксировали в этом ^[10] исследовании. Хотя эксперимент не концентрировался на объеме кода, исследователи выяснили, что глубина проверки ощутимо падает, если ревьюер воспринимает задачу как срочную.

ИИ пришел — лучше не стало

Казалось бы, с приходом разнообразных ИИ-ассистентов вроде Cursor’a и им подобных ситуация должна была измениться. В идеале это должно было выглядеть так: машина генерирует код, а человек внимательно (ведь ресурсы освободились!) рецензирует небольшие порции. Но, видимо, от парадигмы «вкалывают роботы, а не человек» мы все еще далеки. Во-первых, как показало исследование ^[11] LinearB, пул-реквесты кода, сгенерированного с помощью ИИ, в 2.6 раза крупнее по объему чем те, что написаны без ИИ-помощников. Крупные изменения, как правило, затрагивают большее количество файлов и компонентов, повышая вероятность возникновения ошибок. Кроме того, из-за увеличенного объема ревьюеру банально приходится тратить больше времени на проверку. В итоге, даже код был корректен с самого начала, процесс ревью все равно проходит дольше и тяжелее для того, кто его проверяет.

Но есть еще и во-вторых. Согласно отчету ^[12] CodeRabbit, в котором исследователи проанализировали 470 реальных пул-реквестов, ИИ-сгенерированный код содержит в 1.7 раз больше различных дефектов, нежели написанный человеком.

Если на такой код накладывается еще и большой размер пул-реквеста (а ИИ без проблем сгенерирует вам сотни строк за один запрос), получается настоящий «идеальный шторм» — большой объем потенциально дефектного кода.

Укрощение большого пул-реквеста

Так существует ли некий «золотой стандарт» пул-реквеста применительно к объему кода? Давайте разбираться.

В целом в индустрии сходятся во мнении, что оптимальный размер пул-реквеста составляет порядка 200-400 строк. В Best Practices for Code Review ^[13] приводится такая рекомендация:

A SmartBear study of a Cisco Systems programming team revealed that developers should review no more than 200 to 400 lines of code (LOC) at a time. The brain can only effectively process so much information at a time; beyond 400 LOC, the ability to find defects diminishes.

In practice, a review of 200-400 LOC over 60 to 90 minutes should yield 70-90% defect discovery. So, if 10 defects existed in the code, a properly conducted review would find between seven and nine of them.

Обратите внимание не только на указанный объем, но и на временной интервал — 200-400 строк за час-полтора. То есть имеется в виду не просто просмотр кода по диагонали, а вдумчивый анализ, требующий концентрации. 

Похожие цифры и у PropelCode ^[2]: до 100 строк для фиксов багов, 200-400 — для новых фич, 300-500 — в случае рефакторинга. А в Graphite и вовсе призывают стремиться ^[14] к 50 строчкам. Google в своих Engineering Practices ^[15] не дает жесткой цифры, но тоже топит за небольшие изменения — они быстрее и качественнее проверяются, легче откатываются, автор не теряет много времени, если ревьюер отклонит изменение. Никаких жестких рамок в рекомендациях нет, однако указывается, что оптимальный размер — это одно самостоятельное изменение, которое затрагивает лишь одну вещь (например, часть функции, а не функцию целиком). При этом авторы также добавляют, что учитываться должен не только объем изменения, но и количество файлов, которое он затрагивает. 

A 200-line change in one file might be okay, but spread across 50 files it would usually be too large.

Естественно, количество строк кода — метрика довольно грубая сама по себе. На практике размер пул-реквеста стоит оценивать комплексно — сколько файлов затронуто, какова природа правок и т.д. Поэтому лимит в 200-400 строк стоит воспринимать не как жесткие рамки, а скорее как ориентир, который должен корректироваться в зависимости от условий.

А какие практики приняты в вашей команде? Есть ли жесткий лимит на размер пул-реквеста или все решается по ситуации? Используете ли инструменты вроде stacked PRs/diffs или, например, парного программирования для ускорения разработки? Поделитесь в комментариях!