Привет, Хабр. Сегодня я буду рушить один из священных столпов современной разработки. Речь пойдет о код-ревью.
Все мы слышали мантры: «Ревью — это хорошо», «Без ревью нет качества», «Это лучший способ делиться знаниями». И я с этим не спорю. В теории. Но на практике, в суровых реалиях коммерческой разработки с дедлайнами, ограниченными ресурсами и выгорающими тимлидами, код-ревью превратилось в главного тормоза прогресса. В самое узкое горлышко, через которое с трудом просачиваются фичи и исправления.
И это не голословное утверждение. Это вывод, к которому мы пришли, проанализировав данные по нашим проектам за последние два года. Цифры — железные, и они не врут.
О чем мы вообще говорим?
Код-ревью — это не пятиминутное «глянул и апрувнул». Это процесс:
Разработчик создает пулл-реквест (PR/MR).
Ревьюер (чаще всего — самый опытный член команды) откладывает свою текущую задачу, контекстно переключается, изучает код.
Происходит диалог: комментарии, правки, повторные проверки.
Код мержится.
Кажется, ничего сложного. Но дьявол, как всегда, в деталях. И в цифрах.
Кажется, ничего сложного. Но дьявол, как всегда, в деталях. И в цифрах.
Цифры, от которых волосы шевелятся у любого тимлида
Мы собрали статистику по 5+ проектам (веб, блокчейн, высоконагруженные сервисы) и вот что получили.
1. Время — главный ресурс, который мы теряем
Показатель |
Значение |
Комментарий |
|---|---|---|
Среднее время жизни PR |
2.5 рабочих дня |
От создания до мержа |
Ожидание в очереди |
~10 часов |
Senior завален своей работой |
Чистое время работы на PR |
45 минут |
Анализ, комментарии, проверка правок |
Контекстное переключение |
30-40 минут |
15-20 мин на погружение + 15-20 мин на возврат к своим задачам |
Итого время senior'а на PR |
~1.5 часа |
Эффективное время самого дорогого специалиста |
Вывод: Один пулл-реквест стоит команде почти два дня задержки и полтора часа времени senior-разработчика.
2. Экономический удар: считаем деньги
Давайте переведем это в деньги. Возьмем условную команду из 5 человек (3 миддла, 2 сеньора).
Каждый разработчик создает в среднем 3 PR в неделю.
Команда в неделю производит 15 PR.
На ревью этих 15 PR два сеньора тратят:
15 PR * 1.5 часа / 2 сеньора = ~11 часов на каждого.
Это больше целого рабочего дня в неделю! Один день сеньора, который не пишет новую функциональность, не проектирует архитектуру, не решает сложные проблемы. Он ищет запятые и спорные названия переменных в чужом коде.
Грубый расчет: При стоимости часа сеньора условно в 5000 рублей, команда из 5 человек еженедельно тратит на код-ревью около 55 000 рублей. В месяц — ~220 000 рублей. В год — более 2.5 миллионов рублей.
И это — только прямые затраты. Мы еще не считаем упущенную выгоду от задержек выхода фич на рынок.
3. Качество? Не все так однозначно
«Но ведь ревью повышает качество!» — возразите вы.
И будете правы. Но лишь отчасти.
Распределение комментариев в код-ревью:
Тип комментариев |
Доля |
Примеры |
|---|---|---|
Стиль кода и форматирование |
70% |
|
Архитектура и дизайн |
25% |
«Не лучше ли использовать стратегию?», «Нарушение инверсии зависимостей» |
Критические баги |
5% |
Утечки памяти, крайние случаи, NPE |
Что это значит?
А это значит, что львиная доля времени senior'а тратится не на поиск критичных ошибок, а на наведение красоты. Ту самую красоту, которую мог бы и должен бы обеспечивать линтер, настроенный один раз на весь проект.
Мы не отрицаем важность архитектурных споров. Но они тонут в море комментариев про пробелы и запятые.
Последствие №1: Выгорание сеньоров
Представьте себя на месте senior-разработчика. Вам платят за решение сложных задач, а вы вынуждены разгребать десятки PR в день, большую часть которых составляет рутина. Это демотивирует, приводит к эмоциональному выгоранию и, в конечном итоге, к тому, что лучшие кадры начинают искать работу, где их талант будут использовать по назначению.
Ревью из инструмента роста превратилось в каторгу для самых умных.
Последствие №2: Снижение скорости команды
Когда фича «висит» в ревью 2-3 дня, страдает вся команда. Разработчики теряют контекст, не могут двигаться дальше, вынуждены переключаться на другие задачи. Скорость доставки ценности бизнесу падает в разы.
Что делать? Признать проблему
Я не призываю отказываться от код-ревью совсем. Это было бы безумием. Но я призываю перестать делать вид, что текущая модель работает.
Первый шаг к решению — признать, что мы уперлись в потолок. Что код-ревью в его традиционном виде — это роскошь, которую мы не можем себе позволить в условиях быстрого роста и ограниченных ресурсов.
Нужно искать новые подходы. Автоматизировать рутину. Перераспределить нагрузку. Использовать технологии, чтобы освободить человеческий мозг для того, что он действительно умеет делать лучше всего — для сложных архитектурных решений.
Но об этом — в следующей статье, где мы разберем, почему линтеры и статические анализаторы — это лишь капля в море, и что должно прийти им на смену.
А как у вас обстоят дела с код-ревью? Узнали в этих цифрах свою команду? Или, может, ваша статистика выглядит иначе? Жду ваших war stories в комментариях — давайте померимся болью.
С уважением к вашему времени,
Олег Акулов, основатель Nomium.
Комментарии (13)
viordash
26.09.2025 10:355% — это найденные реальные баги
имхо этого достаточно для необходимости код-ревью
70% комментариев в ревью касаются стиля кода и форматирования.
а разве автоформатер кода не решит эту долю проблем?
ALapinskas
26.09.2025 10:35Кроме самих багов, на ревью исправляются архитектурные ошибки, неудачные решения и т.п.
Да и впринципе нужно мониторить, что народ заливает, пасхалку зальют, или того хуже - бекдор сделают, кто будет отвечать?
san-smith
26.09.2025 10:35Кажется у вас проблема с процессами, а не с ревью.
"Ожидание в очереди 10 часов" -- можно взять за правило, например, начинать рабочий день с проведения ревью. Тогда среднее время в худшем случае будет 8 часов. Можно придумать ещё какие-то соглашения.
"львиная доля времени senior'а тратится ... на наведение красоты" -- что мешает таки настроить один раз линтеры и статические анализаторы, чтобы больше не тратить это время?
"львиная доля времени senior'а тратится ..." -- есть мнение, что выполнять ревью могут не только сеньоры. Если не делать их узким горлышком, то они и не будут тормозить разработку.
"Среднее время жизни PR 2.5 дня" -- опять таки, возможно это специфика конкретных стеков/проектов/команд. Потому что так не везде -- особенно, если стремиться делать небольшие PR.
"Чистое время работы на PR 45 минут" -- см. предыдущий пункт. Если подавляющее число PR состоит из 3-5 файлов, с пятком изменений в каждом, то и ревью обычно требует меньше времени.
NovoManu
26.09.2025 10:35В компании не настроены процессы, виновато код ревью.
Почему бы
не настроить линтер/форматтер (предварительно один раз обсудив правила),
поставить pre commit/push чтобы в ПР не проходили исправления линтера,
разбивать задачи максимально на мелкие подзадачи (согласен не всегда это возможно),
не впихивать в ПР несколько изменений (сама задача + рефакторинг + TODO и ид), а только одно изменение на один ПР,
делать информативное описание что ПР делает и какие изменения привносит, чтобы проверяющий получил контекст,
-
сделать код ревью не уделом синьера, а вовлекать всю команду.
Можно ещё много чего написать, но посыл должен быть понятен.
zweroboy1
26.09.2025 10:35Узкое горлышко будет если не делать код ревью и мержить всё подряд без разбора. Тогда в итоге рано или поздно проект докатится до состояния, что и этот сеньор не сможет разгрести все проблемы за адекватное время. Ну а если 70% комментов это правки кодстайла, то я вообще сомневаюсь, что там сеньор. Он бы один раз настроил линтеры и не тратил время на такую ерунду.
inzagher
26.09.2025 10:35У нас ревью не отнимает много времени. Обычно мне(лиду) пишут, просят проверить, я сразу смотрю и пропускаю, либо пишу замечания. Если я не могу, либо нужно, чтобы посмотрели и другие заинтересованные разработчики, пишется сообщение в соответствующий чат. Если срочности нет, то вообще не пишется, в течение дня будет проверено. Два дня ничего не висит. Проверять могут все, ограничений по уровням грейда проверяющих мы не устанавливали. Вдумчиво вчитываться, в основном, приходится, когда разработчик менее опытный(доверия меньше)и реквест очень большой. Тогда, обычно, и замечаний много и времени на просмотр тоже. По соотношению - в основном замечания пишутся на организацию кода(разделение на классы, методы, дублирование, паттерны и т.д.). Либо ошибки при использовании фреймворков. На линтовку замечания единичные, обычно все выдерживают примерный стиль, править его приходится крайне редко. Это при том, что линтера на java у нас не установлено, достаточно того, как помогает ide. Польза от этих мероприятий, однозначно, есть. Качество кода прилично подросло с того момента, когда ревью не было, разработчики не тащат дрянь в зависимости, соблюдают архитектурные требования, даже стажеры пишут нормальный понятный код(после кучи замечаний). Команда больше в курсе, кто что разрабатывает и как это организовано. Баги на ревью ловятся крайне редко, ответственность за них больше на исполнителях.
NatysKi
26.09.2025 10:35Все эти аргументы из разряда эффективного менеджмента.
Все просто, чтобы не казалось, что время и деньги утекают из-за ревью кода, надо всего лишь закладывать время на ревью кода. Все. Это простая истина.
По поводу наведения красоты, а не поиск критических багов. Да, такая проблема имеет место быть. В прошлой моей команде 2-3 человека из 10 делали вдумчивое ревью кода, а не просто для галочки. И, что не удивительно, к таким людям и ходили с просьбой "посмотри мой код, пожалуйста, что думаешь?"
Проблема здесь не в том, что ревью не нужно, а в том, что ревью для галочки не нужно.
Есть ещё товарищи, которые не умеют и не хотят читать чужой код и плохо разбираются в "подкопотной" фундаментальной логике языка, на котором пишут код. И все потому, что в вакансиях есть строчка в требования "умение читать чужой код", но на деле это умение никто не проверяет, а фундаментальные вещи уже давно никто не спрашивает.
Столкнулась недавно с таким выпадом тимлида: "мы это заливать не будем, потому что много кода получилось" (строк 200). И неважно, что там самые базовые и простые вещи написаны с использованием стандартных библиотек, а количество строк идёт засчет переносов. Читай - мы не будем это заливать, потому что мне лень читать твой код, потому что от многабукв у меня случаются лапки.
Итого, дело не в том, что ревью кода это плохо, а в том, что качество кадров, делающих ревью, падает, а также в том, что эффективные менеджеры не учитывают время на ревью разработанного кода, им всем надо побыстрее влить фичу на прод любой ценой.
GoldenSilver
26.09.2025 10:35работаю в Pl/SQL, pgSQL. Лично мой кодревью ограничивается тем, что я нахлобучиваю джуниора, объясняя, как стоит и как не стоит писать, либо оптимизирую уже написанный код. К оформлению не придираюсь - зато по стилю сразу вижу, кто писал ))) своих коллег я бы отсылал на какие нить жесткие курсы, что бы их учили писать оптимальный и красивый код )))
kain64b
26.09.2025 10:35Бред бредовый.. начиная с не настроенного литера. Выгорание на ревью серьезно?
kmatveev
Я сомневаюсь в этих числах.
С чего бы ожидание реквеста стоило всей команде задержки?
И почему в отсутствии линтера виновато review ?
Как-то у вас разработчики быстро теряют контексты.
Статья - нейросетевой мусор с громкими заявлениями.
ExternalWayfarer
Ну так разработчики у них тоже нейросетевые, вот и теряют:)
martin_wanderer
Плюсанул статью. Я тоже сомневаюсь в числах, но в другую сторону. Чтобы погрузиться в контекст задачи, и понять, какая там должна была быть архитектура, иногда требуется пара дней. Не чистого времени, но все же... Почитать ТЗ, понять, что на самом деле хотели, посмотреть, как это повлияет на другие места системы, о влиянии на которые в команде никого даже не думал и не знал...
А есть ещё такой эффект, что ты написал замечаний, а их какие-то поняли не так, какое-то якобы поправили, а на самом деле нет, а вот там просто глупость написана... А на чистоту кода разработчику вообще плевать... И оказывается, что такое ревью просто откладываешь - смотришь тех, кто приличнее делает. А с точки зрения команды - необоснованный простой