Передача знаний через код-ревью

Главная декларируемая причина, по которой команды проводят код-ревью, - "поиск багов". Множество рецензируемых исследований и масштабных индустриальных датасетов сходятся в одном: это заблуждение. Обнаружение багов составляет лишь малую долю реальной пользы ревью. Его главная ценность - передача знаний, осведомлённость команды и поиск альтернативных решений.

Этот вывод влечёт структурные последствия для любого процесса, который оправдывают преимущественно ловлей багов, - например, для блокирующих асинхронных pull request'ов.

Исследования

Microsoft Research, 2015 - "Code Reviews Do Not Find Bugs: How the Current Code Review Best Practice Slows Us Down" (IEEE). Лишь очень небольшой процент комментариев на ревью имел хоть какое-то отношение к багам. Большинство касалось структурных вопросов и стиля.
Bacchelli & Bird, 2013 - "Expectations, Outcomes, and Challenges of Modern Code Review" (ICSE). Изучили практику ревью в Microsoft с помощью наблюдений, интервью и опросов. Менее 15% тем, обсуждаемых на код-ревью, напрямую связаны с багами. Поиск дефектов остаётся главной заявленной целью, но на деле ревью сосредоточено на дефектах гораздо меньше, чем ожидается. Основные результаты: передача знаний, осведомлённость команды, альтернативные решения.
Bosu et al., 2015 - "Characteristics of Useful Code Reviews: An Empirical Study at Microsoft." 1.5 миллиона комментариев к ревью в пяти проектах. Чем больше файлов в изменении -> тем ниже доля полезных комментариев. Ревью изменений объёмом более 20 файлов уже неэффективно.
Крупная технологическая компания, ~9 млн ревью внутри - цитируется у Laforgia: передача знаний даёт основную окупаемость (ROI). До 75% комментариев влияют на эволюционируемость и сопровождаемость ПО, а не на функциональность.
SmartBear/Cisco, 2006 - раннее исследование кейса; ценность ревью уже тогда проявлялась скорее в плоскости сопровождаемости, чем в отлове дефектов.

Причины расхождения

Ревью находит меньше багов, чем ожидается, потому что:

Большинство багов, доживающих до этапа ревью, - концептуальные (ошибочный дизайн, нарушенный инвариант, упущенный краевой случай), а не синтаксические. У рецензентов, читающих diff, нет контекста, который автор нарабатывал часами.
Рецензенты ограничены во времени и чаще комментируют то, что легко заметить с первого взгляда: именование, форматирование, структуру, идиоматичность.
Простые в обнаружении баги всё чаще отлавливаются статическим анализом, linter'ами и тестами ещё до ревью.
Качество ревью на больших изменениях деградирует: порог в >20 файлов от Microsoft означает, что большинство PR'ов уже выходят за рамки осмысленной тщательной проверки.

Более глубокий вывод Bacchelli & Bird: рецензенты не могут поймать то, что не способны восстановить в голове. Им не хватает авторского контекста, поэтому они комментируют то, что видно при чтении вне контекста - стиль, структуру, именование, - и упускают то, что открылось бы лишь при погружении в контекст.

Последствия для парадигмы "PR по умолчанию"

Это ключевой эмпирический аргумент в stop-using-pull-requests. Если главная ценность ревью заключается в передаче знаний, то блокирующая асинхронная очередь - худший из возможных способов её доставки:

Передача знаний наиболее эффективна, когда она контекстна и двунаправленна. Асинхронные комментарии в PR не обладают ни тем, ни другим: автор уже переключился на другую задачу, а у рецензента нет контекста.
Передача знаний гораздо лучше происходит через pair-programming (непрерывно и в контексте), через разборы кода или через обсуждения на этапе проектирования - а не после того, как код уже написан.
Обнаружение дефектов, которое и оправдывало бы блокирующий характер ревью, - ровно то, с чем ревью справляется плохо.

В итоге типичный рабочий процесс с PR оптимизирует не ту пользу не тем механизмом, расплачиваясь за это длительным ожиданием.

Какую пользу ревью всё ещё приносит

Этот вывод не означает "перестаньте рецензировать код". Он означает, что ревью нужно перенести туда, где оно действительно обеспечивает передачу знаний:

Парное / ансамблевое программирование - непрерывное ревью в процессе написания. См. pair-programming.
Неблокирующее ревью после merge - модель Тьерри де По (Thierry de Pauw) из stop-using-pull-requests: ревью в основной ветке после слияния, без блокирующего барьера.
ship-show-ask - сохранение блокирующего ревью только для небольшой части работы, где автору действительно нужна блокирующая обратная связь.
Обсуждение архитектуры до написания кода - переносит передачу знаний на более ранний этап, когда она формирует архитектуру, а не комментирует её постфактум.

Где у этого вывода есть ограничения

Ревью в регулируемых или критически важных для безопасности сферах (медицинские приборы, финансы, аэрокосмическая отрасль) выполняет функции аудита и соответствия стандартам, которые не укладываются в дихотомию "поиск багов против передачи знаний".
Ревью недоверенных внешних правок (open source от незнакомых авторов, inner-source, полувнешние команды) по-прежнему выполняет роль фильтра (gatekeeper) - ради чего PR изначально и создавался. Версию этой проблемы для эпохи LLM см. в i-dont-want-your-prs.
Исследования в основном опираются на опыт Microsoft. Перенос выводов на open source, очень маленькие команды или дисциплины вне разработки ПО выглядит разумным, но прямыми доказательствами не подкреплён.

Связанные страницы

stop-using-pull-requests - полная аргументация Лафорджиа (Laforgia), опирающаяся на этот вывод
pair-programming - предлагаемый механизм получения реальной пользы от ревью
ship-show-ask - приоритизация, сохраняющая блокирующее ревью для случаев, где оно окупается
trunk-based-development - рабочий процесс, который становится возможным, когда ревью перестаёт быть блокирующим барьером
i-dont-want-your-prs - Ченжаркевич (Ciężarkiewicz) о той же проблеме с точки зрения мейнтейнера open source в эпоху LLM
agent-principal-agent-problem - более поздний аргумент Крошоу (Crawshaw) о том, что даже передача знаний обесценивается, когда код пишут агенты
reviewing-ai-code - Депьер (Depierre) применяет ту же литературу по ревью (code-review-throughput-limits) к аргументу "просто проверяйте код за ИИ" и обнаруживает жёсткий потолок пропускной способности