Code review в большинстве команд — это процесс, который начинается с "мнения сеньора" и заканчивается "обиженным автором PR". Такая структура не масштабируется. В команде из 12 человек неясно, кто за что отвечает, merge занимает 3 дня, а обсуждение "почему это отклонено" растягивается на 40 сообщений в Slack. Если копнуть глубже, корень один: правила review завязаны на личные предпочтения, а критерии качества вращаются вокруг "мне нравится/не нравится". За 8+ лет в Roibase применяется простая дисциплина: привяжи review к числовым метрикам, сузь зону для субъективных мнений, форсируй async-процесс. К 2026 году "культура code review" — это не про культуру. Это про измеримые метрики и правила.

Time-to-Review: Хребет Async Workflow

Time-to-review — это время между открытием PR и первым комментарием reviewer'а. Если эта цифра больше 4 часов, async workflow разваливается. Разработчик открыл PR, прошло 6 часов, никто не посмотрел, он переключился на другую задачу — стоимость context switch выросла. В Roibase целевое значение time-to-review — 2 часа. Чтобы удерживать этот показатель, действуют 3 правила: (1) Уведомление о PR автоматическое, в канале Slack пушится и пиннится; (2) Каждый разработчик открывает "review window" дважды в день (11:00 и 16:00); (3) PR не может быть больше 400 строк — если больше, автоматически добавляется лейбл "too large" и блокируется merge.

При внедрении этой системы самое большое сопротивление — "я в это время занят другим". Это правда. Решение: заблокируй time window в календаре, эти 30 минут — твое "review время", других задач там нет. С точки зрения developer experience выигрыш колоссальный: автор PR получает обратную связь по предсказуемому расписанию, не тратит полдня на "а может кто-то посмотрит", может сразу переключиться на новую задачу.

Пример сценария: frontend-разработчик написал новый компонент checkout-flow, открыл PR в 10:30. В 11:00 (review window) backend-lead посмотрел, указал на недостающую обработку ошибок в API интеграции. 11:20 автор сделал fix, в 16:00 (второй review window) одобрение и merge. Итоговое время: 5,5 часов, но активное время — это 2 review window (1 час) + 2 фикс-окна (20 минут). Остаток — параллельная работа. Context switch = 0.

Comment Density: Превращение качества в число

Comment density — это отношение количества комментариев на PR к количеству измененных строк кода. Идеальный диапазон: 1-2 комментария на 50 строк. Если на 50 строк 6 комментариев — либо код действительно плохой, либо reviewer зацепился за мелочи. На 200 строк 0 комментариев — либо код идеален (не реально), либо reviewer не посмотрел.

В Roibase comment density держится в диапазоне 0.02-0.04 (1-2 комментария на 50 строк). Эта метрика отслеживается на еженедельной sprint retrospective. Если comment density разработчика постоянно выше 0.06, есть два варианта: (1) PR'ы приходят низкого качества — нужно усилить pre-commit hooks; (2) Reviewer зацепляется за ненужные детали — в review guide нужно обновить определение "actionable comment".

Actionable comment — имеет структуру "почему" + "как исправить". "Это выглядит плохо" — не actionable. "Эта функция O(n²) — измени loop на line 47 на Map, будет O(n)" — actionable. GitHub Actions workflow Roibase'а автоматически добавляет к каждому PR отчет о comment density. Если она выше 0.06, появляется тревога: "High comment density detected — consider splitting PR or clarifying review focus".

Пример: PR на 250 строк получил 12 комментариев (density: 0.048). Отчет говорит "within range but trending high". На sprint retro выяснилось, что 5 из 12 комментариев про naming convention — значит, лиса eslint правила. На следующем спринте правило включили, density упала до 0.03.

PR Size: Мало строк — быстрый merge

Размер PR — критичнейшая переменная в процессе review. PR больше 400 строк невозможно правильно review'ить. Reviewer либо "беглый взгляд — ok", либо 2 часа на каждую строку — оба варианта неэффективны. Правило Roibase: PR не превышает 400 строк (diff, с пустыми строками и комментариями). Если фича больше —她ломается на несколько маленьких PR'ов, каждый мержится отдельно.

Это правило форсирует две вещи: (1) Разработчик заранее планирует декомпозицию — не "checkout flow", а "checkout validation logic" + "checkout UI components" + "checkout API integration"; (2) Нужна feature branch strategy — PR'ы не идут прямо в main, а мержатся через staging/feature branch.

Пример: интеграция нового payment gateway. Разработчик спланировал 3 PR'а с начала: (1) Gateway API client (250 строк), (2) Internal transaction service layer (300 строк), (3) Frontend checkout widget (200 строк). Каждый review'ился отдельно, общее время merge — 18 часов. Если бы отправил одним PR'ом (750 строк), review время было бы 48+ часов, плюс высокий risk конфликтов.

Контроль размера автоматический. GitHub Actions парсит git diff --stat, если PR превышает 400 строк, добавляется лейбл "pr-too-large" и блокируется merge. Разработчику появляется сообщение: "Split this PR into smaller units".

Закрыть личные конфликты правилами

Самая большая культурная проблема code review — восприятие критики как личной атаки. Разработчик видит PR как "мой код", комментарий читает как "нападение на меня". Чтобы разломать эту психологию, нужно закрыть зону для субъективности. В Roibase применяются 3 метода: (1) Комментарий всегда на конкретную строку кода — общие комментарии запрещены; (2) Каждый комментарий помечается категорией: [blocker], [nit], [question]; (3) Reviewer'ы используют единый чеклист — нет "мне кажется" разных людей.

Blocker — merge невозможен, исправление обязательно (уязвимость безопасности, performance регрессия, падение coverage тестов). Nit — merge возможен, но исправление желательно (отступы, назвать переменную понятнее, добавить комментарий). Question — уточняющий вопрос разработчику (почему именно такой подход, рассматривались ли альтернативы).

В этой системе "мне не нравится" не котируется. Либо есть blocker (числовая причина: coverage < 80%, response time > 200ms), либо nit (style guide нарушен), либо question — но "этот подход неправильный" в чеклисте отсутствует.

Пример: разработчик добавил кэширование на API endpoint, reviewer написал [question] Why memcache instead of Redis? Redis supports TTL per key. Разработчик ответил: "This endpoint has <10 req/sec, memcache sufficient. Redis would add infra cost." Reviewer добавил [nit] Add comment explaining cache choice for future ref. Личного конфликта не было, контекст прояснился.

Async review, sync approval

Процесс review асинхронный, но финальное одобрение синхронное — иначе "мержилось ли это" висит в неопределенности. Workflow Roibase'а: (1) Первый review асинхронный, комментарии в GitHub; (2) Разработчик делает фиксы и добавляет лейбл "ready for re-review"; (3) Re-review в течение 2 часов, либо approval, либо блокирующий комментарий; (4) После approval merge в течение 15 минут — иначе контекст теряется.

В этом потоке sync точка одна: approval → merge. В Roibase это триггирует CI/CD pipeline — в Slack падает "PR #123 merged, deployment started", вся команда видит одновременно. Если разработчик в этот момент занят, может отследить deployment, при нужде быстро откатить.

После merge есть правило "автор на дежурстве 24 часа". Если за сутки после merge'а в production упадет issue — автор PR первый, кто на него реагирует. Это отбивает желание "мержу и забываю", заставляет аккуратнее писать код.

Как Roibase отслеживает review-метрики

За 8 лет операций в Roibase review-дисциплина стала такой же важной, как branding & brand identity — качество общения внутри команды отражается снаружи. После каждого спринта отслеживаются 4 метрики: (1) Средний time-to-review (целевой: <2 часа); (2) Средняя comment density (целевой: 0.02-0.04); (3) Распределение размеров PR (целевой: 90% < 400 строк); (4) Время merge-to-deploy (целевой: <30 минут). Цифры видны в Notion dashboard, обсуждаются на retrospective.

Метрики — не для "пристыдить" разработчика, а для оптимизации системы. Если time-to-review вырос до 3 часов — вопрос: "Review window'ы перегружены или PR-уведомление теряется в Slack?" Если comment density высокий — "Лиснт-правил недостаточно или review guide устарел?"

В этом подходе разработчику не говорят "твой код плохой", а системе спрашивают "где автоматизация сломалась". Результат: улучшается developer experience, конфликтов нет, скорость merge'а не падает.

Code review культура превращается в операционную дисциплину, когда правила числовые. Time-to-review, comment density, лимиты размера PR — это не "красивые рекомендации", это ограничивающие условия. Когда команда растет, разговор переходит с "мнения сеньора" на "критерии системы". За 8 лет в Roibase видно: async workflow масштабируется только если есть метрики. Иначе "культура" это просто слово, и в 12+ человек review process схлопывается в хаос.