Интуиция подсказывает — чем больше пул-реквест, тем выше соблазн по-быстренькому пробежаться глазами по коду и аппрувнуть изменения. Предлагаем вам вместе с нами проверить утверждение из заголовка! В статье посмотрим, к чему пришли исследователи, проанализировавшие 50К+ пул-реквестов, обсудим, какие когнитивные искажения на это влияют, и разберем, как изменилась ситуация с появлением ИИ-помощников. Поехали!
Зона оптимума
Начнем с самого масштабного из доступных исследований. Компания PropelCode проанализировала 50 000+ пул-реквестов и выявила зависимость между количеством найденных ошибок и размером PR. И вот что выяснилось. На маленьких пул-реквестах (до 100 строк) отлавливается почти 9 из 10 ошибок, а когда размер переваливает за тысячу строк — обнаруживается лишь каждая четвертая.
Также, согласно этому же исследованию, есть связь между размером пул-реквеста и содержательностью его обсуждения.
Количество строк | Среднее время проверки | Количество содержательных комментариев |
1-200 | 45 минут | 3.2 |
201-500 | 1.5 часа | 4.1 |
501-1000 | 2.8 часа | 2.9 |
1000+ | 4.2 часа | 1.8 |
Иными словами, чем больший объем проверяет рецензент, тем меньше вопросов он задает и тем реже находит и указывает на потенциальные проблемы.
Почему мозг саботирует большие PR
Исследователи считают, что виной всему — вполне конкретные человеческие ограничения. Разработчик, открывающий дифф на тысячу строк, физически не способен удержать в голове всю картину изменений — и дело тут не в недостатке опыта, а в устройстве нашего мозга.
Магическое число 7±2 и когнитивная перегрузка
Согласно правилу Миллера, кратковременная рабочая память человека способна удерживать одновременно 7 ± 2 объекта, проще говоря, от 5 до 9. Когда рецензент просматривает код, он оперирует не отдельными символами, а кусочками — логическими блоками. В небольшом пул-реквесте таких блоков немного, и мозг успевает построить цельную модель изменения. Однако большие пул-реквесты человеческий мозг не всегда в состоянии полноценно переварить, что вынуждает рецензента обходиться лишь поверхностным анализом, сравнивая код со знакомыми паттернами и шаблонами.
Ловушка масштаба
Еще коварнее феномен, который называют пренебрежением масштабом (scope insensitivity). В случае в ревью работает это так. Наш мозг выделяет примерно одинаковый объем ментальных усилий на анализ пул-реквеста как в 100, так и в 1000 строк. Чем больше объем кода, тем меньше внимания получит каждая из них.
Влияние срочности
Есть и третий фактор, который редко обсуждают в контексте размера пул-реквеста, хотя он способен кратно усилить описанные выше эффекты. Пул-реквест большого объема нередко воспринимается ревьюером как срочный — коллега писал его несколько дней, а значит, сроки поджимают и надо побыстрее просмотреть, чтобы не стопорить команду. В этом случае на ревьюера с высокой долей вероятности будет давить не только непосредственно объем пул-реквеста, но и этот фактор срочности. Торопясь закрыть «висяк», разработчик может быстро пролистать дифф, поправить пару стилистических мелочей, оставить комментарий в духе «вроде норм» и аппрувнуть изменение.
Именно такую модель поведения и зафиксировали в этом исследовании. Хотя эксперимент не концентрировался на объеме кода, исследователи выяснили, что глубина проверки ощутимо падает, если ревьюер воспринимает задачу как срочную.
ИИ пришел — лучше не стало
Казалось бы, с приходом разнообразных ИИ-ассистентов вроде Cursor’a и им подобных ситуация должна была измениться. В идеале это должно было выглядеть так: машина генерирует код, а человек внимательно (ведь ресурсы освободились!) рецензирует небольшие порции. Но, видимо, от парадигмы «вкалывают роботы, а не человек» мы все еще далеки. Во-первых, как показало исследование LinearB, пул-реквесты кода, сгенерированного с помощью ИИ, в 2.6 раза крупнее по объему чем те, что написаны без ИИ-помощников. Крупные изменения, как правило, затрагивают большее количество файлов и компонентов, повышая вероятность возникновения ошибок. Кроме того, из-за увеличенного объема ревьюеру банально приходится тратить больше времени на проверку. В итоге, даже код был корректен с самого начала, процесс ревью все равно проходит дольше и тяжелее для того, кто его проверяет.
Но есть еще и во-вторых. Согласно отчету CodeRabbit, в котором исследователи проанализировали 470 реальных пул-реквестов, ИИ-сгенерированный код содержит в 1.7 раз больше различных дефектов, нежели написанный человеком.
Если на такой код накладывается еще и большой размер пул-реквеста (а ИИ без проблем сгенерирует вам сотни строк за один запрос), получается настоящий «идеальный шторм» — большой объем потенциально дефектного кода.
Укрощение большого пул-реквеста
Так существует ли некий «золотой стандарт» пул-реквеста применительно к объему кода? Давайте разбираться.
В целом в индустрии сходятся во мнении, что оптимальный размер пул-реквеста составляет порядка 200-400 строк. В Best Practices for Code Review приводится такая рекомендация:
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: до 100 строк для фиксов багов, 200-400 — для новых фич, 300-500 — в случае рефакторинга. А в Graphite и вовсе призывают стремиться к 50 строчкам. Google в своих Engineering Practices не дает жесткой цифры, но тоже топит за небольшие изменения — они быстрее и качественнее проверяются, легче откатываются, автор не теряет много времени, если ревьюер отклонит изменение. Никаких жестких рамок в рекомендациях нет, однако указывается, что оптимальный размер — это одно самостоятельное изменение, которое затрагивает лишь одну вещь (например, часть функции, а не функцию целиком). При этом авторы также добавляют, что учитываться должен не только объем изменения, но и количество файлов, которое он затрагивает.
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 или, например, парного программирования для ускорения разработки? Поделитесь в комментариях!