Код-ревью

Время освоения: ~35 минут Цель: Научиться диагностировать проблемы команды по данным о код-ревью и менять то, что действительно в зоне влияния руководителя — процесс, настройки и распределение нагрузки, а не формулировки отдельных комментариев

Правая колонка меняется только косвенно — через левую. Это главная мысль урока.

Руководители обычно приходят к теме код-ревью с одной из двух жалоб: «ревью тормозит поставку» или «баги проходят через ревью в прод». Реже — с третьей, самой важной: «знания сосредоточены в двух людях, и я не могу отпустить их в отпуск одновременно».

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

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

Ревью решает три задачи одновременно, и они тянут в разные стороны. Понимание конфликта — половина работы руководителя.

Контроль качества. Требует времени, внимательности и опытных ревьюеров. Максимум качества достигается при малых PR и двух-трёх ревью на изменение — то есть при медленной поставке.

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

Скорость поставки. Требует минимума раундов и минимума обязательных одобрений.

Типичная управленческая ошибка — оптимизировать одну функцию, не назвав цену. Введение трёх обязательных одобрений повышает контроль и убивает скорость. Требование «ревьюить в течение часа» повышает скорость и убивает качество. Ротация областей распространяет знания и замедляет всё.

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

Прежде чем что-то менять, нужны данные. Выгружаются из GitHub или GitLab, считаются один раз, дальше обновляются автоматически.

Медиана размера PR. Главный входной параметр. Если она выше 400 строк, все остальные проблемы вторичны: внимательность ревьюера на таком объёме не обеспечивается ничем, и любые требования к качеству ревью останутся пожеланиями. Важно: это чинится не правилом «PR не больше 400 строк», а декомпозицией задач в бэклоге — то есть на планировании, где вы присутствуете.

Время до первого ответа. Медиана в рабочих часах. Формирует у авторов ощущение «моя работа не важна». Ориентир — до 4 часов. Высокое значение почти всегда означает, что ревьюер не назначается автоматически: PR без адресата ждёт дольше всех, потому что каждый думает, что посмотрит другой.

Время повторного ответа. Считается отдельно от первого и почти всегда оказывается хуже. Причина: после правок PR уходит в конец очереди. При трёх раундах именно это число определяет общий срок. Самое дешёвое улучшение из всех — отдельный SLA на повторное ревью.

Доля ревью на человека. Единственная метрика, которую нужно смотреть персонально, — но как сигнал перегрузки, а не усердия. Больше 40 % у одного человека означает узкое место, риск выгорания и концентрацию знаний.

Пятое число, если есть возможность его получить, важнее всех: доля изменений, приведших к инциденту. Это единственная метрика результата; без неё дашборд всегда будет улучшаться за счёт результата.

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

Работает другое: правило, перенесённое в настройки репозитория. Его нельзя не заметить и нельзя обойти незаметно.

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

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

Здесь работает не то, что вы говорите, а то, что делаете.

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

Просите ревью у junior-разработчиков. Не ради качества проверки, а чтобы показать: ваш код тоже проверяется, и вопросы к нему нормальны.

Высказывайтесь в спорных тредах последним. Мнение руководителя, высказанное первым, завершает обсуждение независимо от аргументов, и команда лишается собственного вывода.

Не будьте обязательным ревьюером. Иначе «одобрено руководителем» перестаёт быть техническим решением, а вы становитесь узким местом.

Пресекайте личные выпады немедленно и в том же треде. Реакция, которой не видно, не меняет норму: остальные видели только выпад.

Не решайте споры в личных сообщениях. Конфликт видели все, а его разрешение — никто, и норма не изменилась.

Полезно знать границы, чтобы не требовать от процесса невозможного.

Ревью почти не ловит: гонки, воспроизводящиеся редко; деградацию производительности на реальном объёме; утечки памяти; регрессию в редком сценарии. Это работа тестов, нагрузочных стендов и мониторинга. Если инциденты приходят из этой категории, ужесточение ревью не поможет — нужны другие практики.

Ревью не заменяет постановку задачи. Если спор в PR идёт о том, что вообще надо было делать, проблема возникла на планировании. Признак: обсуждение целесообразности задачи начинается после того, как код написан.

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

Выгрузите из GitHub или GitLab за последние три месяца:

Сопоставьте с таблицей диагностики в начале урока. Выберите одно изменение — то, что дальше всех от ориентира, — и реализуйте его на этой неделе. Не пять сразу: иначе не будет понятно, что подействовало.

Откройте настройки защиты основной ветки и сравните с тем, что команда считает обязательным. Проверьте отдельно:

Возьмите три закрытых спорных PR. Каждый участник независимо расставляет уровни всем замечаниям (blocker / major / minor / nit). Сравните, обсудите только расхождения, запишите договорённости в CONVENTIONS.md.

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

Управленческая работа в код-ревью почти вся находится до самого ревью: в декомпозиции задач, в назначении ревьюеров, в настройках репозитория и в том, зафиксированы ли договорённости. Внутри тредов вы влияете только личным примером — и это влияние сильнее, чем любое объявление о ценностях.

Ключевые выводы:

Время освоения: 35 минут Уровень: Продвинутый Для кого: Тимлиды, Engineering Managers, Senior Engineers Подробнее: Code Review для команды — процесс, метрики, культура и конфликты в деталях