Перегляд коду — найвужче місце в розробці. І ось цифри, які це доводять

Привіт, Хабр. Сьогодні я руйнуватиму один із священних стовпів сучасної розробки. Йдеться про код-рев'ю.

Усі ми чули мантри: «Рев'ю — це добре», «Без рев'ю немає якості», «Це найкращий спосіб ділитися знаннями». І я з цим не сперечаюся. У теорії. Але на практиці, в суворих реаліях комерційної розробки з дедлайнами, обмеженими ресурсами та вигораючими тімлідами, код-рев'ю перетворилося на головне гальмо прогресу. На найвужче місце, через яке з труднощами просочуються фічі та виправлення.

І це не голослівне твердження. Це висновок, до якого ми дійшли, проаналізувавши дані по наших проєктах за останні два роки. Цифри — залізні, і вони не брешуть.

Про що ми взагалі говоримо?

Код-рев'ю — це не п'ятихвилинне «глянув і апрувнув». Це процес:

1. Розробник створює пул-реквест (PR/MR).
2. Рев'юер (найчастіше — найдосвідченіший член команди) відкладає свою поточну задачу, контекстно перемикається, вивчає код.
3. Відбувається діалог: коментарі, правки, повторні перевірки.
4. Код мерджиться.

Здається, нічого складного. Але диявол, як завжди, в деталях. І в цифрах.

Здається, нічого складного. Але диявол, як завжди, в деталях. І в цифрах.

Цифри, від яких волосся стає дибки у будь-якого тімліда

Ми зібрали статистику по 5+ проєктах (веб, блокчейн, високонавантажені сервіси) і ось що отримали.

1. Час — головний ресурс, який ми втрачаємо

Висновок: Один пул-реквест коштує команді майже два дні затримки і півтори години часу senior-розробника.

2. Економічний удар: рахуємо гроші

Давайте переведемо це в гроші. Візьмемо умовну команду з 5 осіб (3 мідли, 2 сеньйори).

1. Кожен розробник створює в середньому 3 PR на тиждень.
2. Команда на тиждень виробляє 15 PR.
3. На рев'ю цих 15 PR два сеньйори витрачають: 15 PR * 1.5 часа / 2 сенйора = ~11 годин на кожного.

Це більше цілого робочого дня на тиждень! Один день сеньйора, який не пише нову функціональність, не проектує архітектуру, не вирішує складні проблеми. Він шукає коми та спірні назви змінних у чужому коді.

І це — тільки прямі витрати. Ми ще не рахуємо упущену вигоду від затримок виходу фіч на ринок.

3. Якість? Не все так однозначно

«Але ж рев'ю підвищує якість!» — заперечите ви.

І будете праві. Але лише частково.

Розподіл коментарів у код-рев'ю:

Що це означає?

А це означає, що левова частка часу senior'а витрачається не на пошук критичних помилок, а на наведення краси. Ту саму красу, яку міг би і повинен забезпечувати лінтер, налаштований один раз на весь проєкт.

Ми не заперечуємо важливість архітектурних спорів. Але вони тонуть у морі коментарів про пробіли та коми.

Наслідок №1: Вигорання сеньйорів

Уявіть себе на місці senior-розробника. Вам платять за вирішення складних задач, а ви змушені розгрібати десятки PR на день, більшу частину яких становить рутина. Це демотивує, призводить до емоційного вигорання і, зрештою, до того, що найкращі кадри починають шукати роботу, де їхній талант використовуватимуть за призначенням.

Рев'ю з інструменту зростання перетворилося на каторгу для найрозумніших.

Наслідок №2: Зниження швидкості команди

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

Що робити? Визнати проблему

Я не закликаю відмовлятися від код-рев'ю зовсім. Це було б божевіллям. Але я закликаю припинити вдавати, що поточна модель працює.

Перший крок до рішення — визнати, що ми впираємося в стелю. Що код-рев'ю в його традиційному вигляді — це розкіш, яку ми не можемо собі дозволити в умовах швидкого зростання та обмежених ресурсів.

Потрібно шукати нові підходи. Автоматизувати рутину. Перерозподілити навантаження. Використовувати технології, щоб звільнити людський мозок для того, що він дійсно вміє робити найкраще — для складних архітектурних рішень.

Але про це — в наступній статті, де ми розберемо, чому лінтери та статичні аналізатори — це лише крапля в морі, і що повинно прийти їм на зміну.