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

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

И это не голословное утверждение. Это вывод, к которому мы пришли, проанализировав данные по нашим проектам за последние два года. Цифры — железные, и они не врут.

О чем мы вообще говорим?

Код-ревью — это не пятиминутное «глянул и апрувнул». Это процесс:

1. Разработчик создает пулл-реквест (PR/MR).

2. Ревьюер (чаще всего — самый опытный член команды) откладывает свою текущую задачу, контекстно переключается, изучает код.

3. Происходит диалог: комментарии, правки, повторные проверки.

4. Код мержится.

Кажется, ничего сложного. Но дьявол, как всегда, в деталях. И в цифрах.

Кажется, ничего сложного. Но дьявол, как всегда, в деталях. И в цифрах.

Цифры, от которых волосы шевелятся у любого тимлида

Мы собрали статистику по 5+ проектам (веб, блокчейн, высоконагруженные сервисы) и вот что получили.

1. Время — главный ресурс, который мы теряем

Вывод: Один пулл-реквест стоит команде почти два дня задержки и полтора часа времени 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. Качество? Не все так однозначно

«Но ведь ревью повышает качество!» — возразите вы.
И будете правы. Но лишь отчасти.

Распределение комментариев в код-ревью:

Что это значит?
А это значит, что львиная доля времени senior'а тратится не на поиск критичных ошибок, а на наведение красоты. Ту самую красоту, которую мог бы и должен бы обеспечивать линтер, настроенный один раз на весь проект.

Мы не отрицаем важность архитектурных споров. Но они тонут в море комментариев про пробелы и запятые.

Последствие №1: Выгорание сеньоров

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

Ревью из инструмента роста превратилось в каторгу для самых умных.

Последствие №2: Снижение скорости команды

Когда фича «висит» в ревью 2-3 дня, страдает вся команда. Разработчики теряют контекст, не могут двигаться дальше, вынуждены переключаться на другие задачи. Скорость доставки ценности бизнесу падает в разы.

Что делать? Признать проблему

Я не призываю отказываться от код-ревью совсем. Это было бы безумием. Но я призываю перестать делать вид, что текущая модель работает.

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

Нужно искать новые подходы. Автоматизировать рутину. Перераспределить нагрузку. Использовать технологии, чтобы освободить человеческий мозг для того, что он действительно умеет делать лучше всего — для сложных архитектурных решений.

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

А как у вас обстоят дела с код-ревью? Узнали в этих цифрах свою команду? Или, может, ваша статистика выглядит иначе? Жду ваших war stories в комментариях — давайте померимся болью.

С уважением к вашему времени,
Олег Акулов, основатель Nomium.