2.9 Метрики пулл-реквестов и ревью кода

Обзор и мотивация

Ревью кода обычно единственный крупнейший источник времени ожидания внутри разбивки времени цикла из темы 2.6, и это также этап, наиболее напрямую находящийся под собственным контролем команды для улучшения, в отличие от общего платформенного узкого места или внешней зависимости. Эта тема покрывает конкретные метрики, живущие внутри этапа ревью: время до первого ревью, размер пулл-реквеста, число итераций ревью и распределение нагрузки рецензентов, и как использовать их для улучшения скорости ревью, не жертвуя фактической пользой качества, которую ревью призвано предоставлять.

Риск, к которому эта тема наиболее насторожена, это тот, который эта книга ещё не покрывала напрямую: оптимизация скорости ревью может тихо подорвать качество ревью, если преследуется неосторожно. Команда, вдвое сократившая своё время до первого ревью, одобряя всё штампом, улучшила метрику, уничтожив фактическую ценность практики. Каждая рекомендация в этой теме написана с учётом этого компромисса, потому что метрики пулл-реквестов одни из самых простых в этой книге для манипулирования способом, выглядящим хорошо на дашборде, при этом измеримо ухудшая лежащую в основе кодовую базу.

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

Ключевые принципы

Время до первого ревью обычно самый большой рычаг, а не тщательность самого ревью. Большая часть задержки происходит от того, что пулл-реквест ждёт, чтобы на него посмотрели, а не от того, что разговор ревью занимает долго, как только он начинается.
Меньшие пулл-реквесты рецензируются быстрее и тщательнее, а не только быстрее. Размер это точка рычага одновременно и для скорости, и для качества.
Скорость ревью и качество ревью автоматически не находятся в противоречии, но ими можно неосторожно пожертвовать друг ради друга. Защищайтесь от этого обмена явно.
Дисбаланс нагрузки рецензентов распространён и обычно невидим без метрики. Небольшое число людей часто поглощает непропорциональную долю.
Эти метрики подвержены риску манипулирования штампованием. Быстрое одобрение без реальной проверки сводит на нет весь смысл ревью.

Компромиссы: плюсы и минусы

Подход	Плюсы	Минусы
Оптимизация исключительно времени до первого ревью	Быстрый ясный сигнал, легко инструментировать	Может стимулировать поверхностное штампованное ревью без защиты
Оптимизация исключительно сокращения размера пулл-реквеста	Улучшает одновременно и скорость, и тщательность	Не вся работа чисто разбивается на мелкие приращения
Равномерное вращение нагрузки ревью	Снижает узкое место и риск выгорания	Может замедлить ревью для специализированного трудно рецензируемого кода, требующего конкретной экспертизы
Концентрация ревью среди старших инженеров	Глубокая доменная экспертиза, применяемая последовательно	Со временем создаёт узкое место и риск выгорания

Центральное напряжение: скорость против глубины проверки. Каждая техника в этой теме для ускорения ревью, более быстрый первый ответ, меньшие пулл-реквесты, более распределённая нагрузка рецензентов, несёт некоторый риск отказа от реальной проверки, если преследуется без страховочной метрики качества, которую рекомендует эта тема. Разрешайте это напряжение, сочетая каждую метрику скорости с сигналом качества, отслеживаемым за тот же период, чтобы команда могла отличить подлинное улучшение процесса от тихо разрушающегося стандарта ревью.

Вопросы для обсуждения в команде

Каково наше фактическое время до первого ревью, и сколько нашего общего времени цикла потребляет этап ревью? Возьмите реальное число, а не полагайтесь на впечатление; время ожидания ревью часто больше, чем предполагают команды, именно потому, что легко недооценить время, потраченное на ожидание, а не на активную работу.
Каков наш медианный размер пулл-реквеста, и насколько сократилась бы наша задержка ревью, если бы этот размер уменьшился? Большие пулл-реквесты и медленнее рецензируются, и с большей вероятностью получают поверхностное ревью просто потому, что рецензент не может удержать всё в голове одновременно. Посмотрите на ваше фактическое распределение размеров, а не только на медиану.
Концентрируется ли нагрузка ревью среди небольшого числа людей, и что случилось бы с нашей пропускной способностью ревью, если бы один из них был недоступен две недели? Этот вопрос раскрывает одновременно и риск узкого места, и риск выгорания. Возьмите фактические данные о нагрузке рецензентов, а не полагайтесь на впечатление.
Улучшали ли мы когда-либо метрику скорости ревью способом, который при размышлении сократил фактическую проверку? Будьте честны здесь; это именно риск штампования, который называет эта тема, и в него легко соскользнуть без какого-либо сознательного решения это сделать.
Что обычно сигнализирует высокое число итераций ревью в нашей команде: подлинное разногласие, неясные требования или непоследовательные ожидания стиля? Посмотрите на выборку пулл-реквестов с необычно высоким числом итераций и диагностируйте фактический паттерн, а не предполагайте, что он плохо отражается на авторе или рецензенте.
Есть ли у нас страховочная метрика качества, сочетаемая с нашими метриками скорости ревью, или мы отслеживаем скорость изолированно? Если честный ответ в том, что такой страховочной метрики не существует, это пробел, достойный закрытия до дальнейшего продвижения скорости ревью, согласно принципу сочетания темы 1.2.

Отраслевой взгляд

Стартап. Ревью часто по умолчанию быстрое с маленькой командой, иногда почти слишком быстрое, ревью с единственным утверждающим и минимальной проверкой, потому что все доверяют всем. Риск, за которым нужно следить по мере роста команды, в том, что качество ревью не масштабируется вместе с размером команды, поскольку неформальное доверие, работавшее для пяти инженеров, автоматически не работает для пятидесяти.

Малый бизнес. Большинство платформ контроля версий сообщают статистику времени до слияния и числа ревью из коробки; используйте их вместо построения кастомного инструментирования. Главная дисциплина, которую стоит принять, просто замечать, концентрировалась ли нагрузка ревью тихо на одном-двух людях по мере роста команды.

Корпорация. Дисбаланс нагрузки рецензентов и узкие места специализированных знаний особенно распространены здесь, где глубокая доменная экспертиза в критической системе может концентрировать ответственность за ревью на небольшой группе независимо от размера команды. Инвестируйте в сознательный обмен знаниями и вращение ревью, чтобы распространить экспертизу, снижая и узкое место, и риск фактора автобуса от того, что эта экспертиза живёт у слишком малого числа людей.

Государство. Процессы ревью здесь часто несут вес соответствия требованиям наряду с целями качества, что может делать пулл-реквесты больше, а ревью медленнее по замыслу. Там, где подлинные требования соответствия требуют тщательного ревью, сосредоточьте усилия улучшения на сокращении времени ожидания (более быстрое назначение ревью, более ясная триажа), а не на компромиссе фактической глубины ревью, и явно документируйте компромисс, если проверка должна оставаться строгой по регуляторным причинам.

Примеры

Корпорация. Инженерная организация компании кибербезопасности обнаружила, что горстка главных инженеров завершала более 40% всех ревью кода по организации из двухсот человек, дисбаланс, который никто не измерял напрямую, пока не были взяты данные о нагрузке рецензентов. Эта концентрация была одновременно узким местом, поскольку доступность этих инженеров ограничивала пропускную способность ревью для всей организации, и риском выгорания, отдельно отмеченным опросом вовлечённости (тема 3.2). Организация ввела структурированную программу вращения ревью в сочетании с целевыми сессиями обмена знаниями, и в течение двух кварталов нагрузка ревью распространилась на гораздо более широкую группу, с временем до первого ревью, улучшившимся как прямой побочный эффект сокращённого узкого места.

Государство. Инженерная команда налогового органа, под давлением улучшить скорость доставки, установила цель вдвое сократить время до первого ревью. В течение одного квартала цель была достигнута, но последующий аудит качества обнаружил резкий рост пулл-реквестов с исправлением дефектов после слияния, сконцентрированных в изменениях, одобренных единственным кратким комментарием. Исправление команды сочетало цель скорости с явной страховочной метрикой качества, частотой исправлений после слияния, необходимых в течение двух недель после ревью, и переобучило команду тому, что фактически требовало содержательное ревью, восстановив подлинную проверку, сохранив при этом большую часть улучшения скорости, пришедшего от лучшего назначения ревью и меньших размеров пулл-реквестов.

Бизнес-кейс: мотивация, ROI и TCO

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

Полная стоимость владения низкая: большинство этих метрик приходит напрямую из существующих данных платформы контроля версий с минимальным дополнительным инструментированием, а изменения процесса, на которые они указывают, вращение ревью, поощрение меньших пулл-реквестов, стоят в основном дисциплины, а не инвестиций в инструментарий.

Антипаттерны и ловушки

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

Модель зрелости

Уровень 1, Инициация: Метрики ревью не отслеживаются; распределение нагрузки ревью и размер пулл-реквеста невидимы.
Уровень 2, Развитие: Некоторые данные скорости ревью существуют из настроек платформы по умолчанию, но нет страховочной метрики качества и нет активного управления нагрузкой рецензентов.
Уровень 3, Стандартизация: Время до первого ревью, размер пулл-реквеста и нагрузка рецензентов отслеживаются последовательно, с явной страховочной метрикой качества, сочетаемой с улучшениями скорости.
Уровень 4, Управление: Нагрузка рецензентов активно перебалансируется через вращение и обмен знаниями; паттерны числа итераций исследуются на уровне процесса, а не индивидуальном уровне.
Уровень 5, Оркестрация: Метрики этапа ревью напрямую информируют инвестиции в процесс, и организация может продемонстрировать одновременное улучшение и скорости ревью, и связанных с ревью результатов качества за устойчивый период.

Идеи для обсуждения

Каково наше текущее медианное время до первого ревью, и куда на самом деле уходит это время?
Концентрируется ли наша нагрузка ревью на небольшом числе людей, и каков риск, если один из них недоступен?
Улучшали ли мы когда-либо скорость ревью за счёт реальной проверки, даже непреднамеренно?
Каков наш медианный размер пулл-реквеста, и насколько меньше реалистично могли бы быть большинство изменений?
Относимся ли мы к высокому числу итераций ревью как к системному сигналу или индивидуальному суждению?

Основные выводы

Время до первого ревью обычно самый большой единственный рычаг внутри этапа ревью, больше, чем сама длина разговора ревью.
Меньшие пулл-реквесты одновременно улучшают и скорость ревью, и тщательность ревью.
Дисбаланс нагрузки рецензентов распространён и обычно невидим без прямого измерения; он создаёт одновременно узкое место и риск выгорания.
Сочетайте каждую метрику скорости ревью с явной страховочной метрикой качества, чтобы поймать риск манипулирования штампованием, которому особенно подвержено это семейство метрик.
Используйте число итераций ревью для диагностики трения на системном уровне, а не для суждения об отдельных авторах или рецензентах.

Источники и дальнейшее чтение

Accelerate: The Science of Lean Software and DevOps, Николь Форсгрен, Джез Хамбл и Джин Ким.
Исследование Modern Code Review Альберто Баккелли и Кристиана Бёрда.
Peer Reviews in Software: A Practical Guide, Карл Э. Вигерс.
The Principles of Product Development Flow, Дональд Г. Рейнертсен.

2.9 Метрики пулл-реквестов и ревью кода

Обзор и мотивация

Ключевые принципы

Рекомендации

Отслеживайте время до первого ревью как основную метрику скорости

Отслеживайте размер пулл-реквеста и активно поощряйте меньшие изменения

Явно отслеживайте распределение нагрузки рецензентов

Явно защищайтесь от риска манипулирования штампованием

Используйте число итераций ревью, чтобы заметить трение, а не судить отдельных людей