Прямой ответ
Code review работает, когда настроены три параметра: размер (PR ≤ 200–400 строк диффа — качество замечаний падает нелинейно с объёмом; большие изменения режутся на стеки PR — ветвление с короткими ветками делает это естественным), скорость (первый ответ в течение рабочего дня — «ревью за три дня» убивает throughput команды сильнее, чем отсутствие ревью), и фокус (ревьюер проверяет то, что не ловит автоматика: корректность логики, краевые случаи, безопасность, читаемость и дизайн — форматирование, стиль, типовые ошибки — линтер/CI, не человек). Чек-лист ревьюера по слоям: корректность (делает ли код заявленное; краевые случаи — пусто/None/дубли/гонка; ошибки обработаны — исключения), тесты (покрывают новое поведение и краевые, не только happy path), безопасность (новый ввод — проверен; новый доступ — авторизован; новый запрос — параметризован — OWASP-чеклист как раздел ревью), читаемость (имена объясняют намерение; сложность оправдана; «я не понял за два чтения — переименуй/разбей»), дизайн (на своём месте ли изменение; не дублирует ли существующее; совместимость контрактов). Культура решает не меньше процесса: замечания — коду, не автору (conventional comments: suggestion:, question:, nit: — серьёзность явна), вопрос вместо утверждения там, где нет уверенности, и обязательное «что хорошо» — ревью без признания хорошей работы выгорает в критику.
Слои проверки: что человек, что машина
Разделение труда — фундамент: машина — форматирование (black/ruff format), стиль (ruff — настройка), типы (mypy), тесты, покрытие, уязвимости зависимостей, секреты в диффе (gitleaks) — всё это required checks CI до ревью (ревьюер не тратит внимание на запятые — их не должно быть в диффе: pre-commit их уже съел — хуки); человек — то, что требует контекста: логика и краевые случаи (тесты есть, но проверяют ли они то, что надо — вопрос ревьюера), дизайн (правильное ли место для кода — знание кодовой базы), производительность в контексте данных (запрос в цикле — N+1 видно знающему — N+1), безопасность по смыслу (авторизация на новый эндпоинт; данные в логах), сопровождаемость (через полгода этот код будет править другой — читается ли). LLM-ассистенты ревью (CI-бот) — дополнительный слой «механических» замечаний между машиной и человеком (забытый close, проглоченное исключение) — но аппрув ставит человек: ответственность и контекст не делегируются модели.
Размер, скорость, процесс
Практика малых PR: автор режет изменение на самодостаточные части (рефакторинг отдельно от поведения — классическое разделение; подготовка интерфейса, затем использование), каждый PR — рабочая кодовая база (фича-флаги для незавершённого — флаги); «не могу разбить» — почти всегда «не хочу» или признак запутанного изменения (ревью большого диффа это подтвердит качеством). Скорость как метрика: время до первого ответа < 4 часов в рабочее время (автор не блокирован), итераций до мержа ≤ 2–3 (больше — либо размер, либо недопонимание задачи — синхронно обсудить голосом дешевле четвёртой итерации); приоритет ревью — над написанием нового кода у ревьюера (командное соглашение: «мой PR ждёт — иду ревьюить чужой»). Процессные детали, которые экономят часы: описание PR — контекст и «что проверять» (скриншоты для UI, curl-примеры для API), self-review перед запросом (автор проходит дифф сам — треть замечаний умирает здесь), черновики для ранней обратной связи (draft PR на 20% готовности — направление согласовано до полного кода).
Культура комментариев: критика без токсичности
Формат замечания: факт + влияние + предложение («здесь retry без backoff — при отказе партнёра положим его повторами; добавь экспоненциальную задержку — паттерн») вместо оценки («это плохо»); вопросы вместо вердиктов при неочевидном («как этот код поведёт себя при дубле вебхука?» — автор отвечает и часто правит сам — обучает без конфронтации); nit: для вкусового (не блокирует мерж — явная маркировка снимает оборону); хвала конкретная («отличная декомпозиция парсера — тесты читаются как спецификация») — закрепляет хорошее. Отдельные правила: замечания не накапливать залпом на 40 комментариев (3–5 ключевых + «остальное мелочи, поправь по ходу» — лавина демотивирует); разногласия — эскалация с таймбоксом (два круга переписки не сошлись — созвон 10 минут или решение лида — бесконечные ветки комментариев токсичнее любого кода); авторство кода после мержа — командное («твой код» в будущем — токсичный паттерн владения). Ревью обучает: джуны растут на чужих замечаниях быстрее любых курсов; ротация ревьюеров (не только сеньоры) — знание кодовой базы распределяется.
Практический сценарий: настройка ревью в растущей команде
Старт: 5 разработчиков, ревью формальное — «LGTM за час без чтения» у одних, недельные зависания у других; конфликт из-за вкусовых замечаний в стиле. Настройка за спринт: (1) автоматизация до человека — ruff+black+mypy required, pre-commit локально, секреты-сканер — вкусовые споры исчезли вместе с предметом; (2) соглашение размера — 400 строк потолок (больше — разбивать; рефакторинг и фичи — раздельные PR — правило записано в CONTRIBUTING); (3) SLA первого ответа — 4 рабочих часа, ревью приоритетнее новых фич (договорённость, не политика кнута); (4) conventional comments (nit/question/suggestion/blocker) — серьёзность видна, «вкусовое» маркировано и не блокирует; (5) шаблон PR (что/зачем/как проверено/скрины) — ревьюер стартует с контекстом. Замеры через квартал: медиана времени до мержа — 26 часов → 7; итераций — 3.4 → 1.8; два реальных бага пойманы на ревью (гонка в кеше, отсутствующая проверка прав на новый эндпоинт — второй — безопасность: чек-лист OWASP-раздела сработал); джуны отмечают, что замечания с объяснением «почему» — главный источник обучения. LLM-бот добавили позже — ловит забытые close/ресурсы до человека; аппрув остался человеческим.
FAQ
Нужно ли ревью для мелких правок (опечатка, конфиг)? Да, но лёгкое (быстрый аппрув без глубокого чтения — риск не в размере диффа, а в «безобидных» правках конфига — половина прод-инцидентов из таких); исключение — hotfix-процедура (пост-фактум ревью в тот же день — скорость важнее, контроль не отменяется).
Что делать, если ревьюер придирается к стилю вопреки линтеру? Линтер — арбитр стиля (его правила согласованы командой — ruff-конфиг): замечания вне линтера по стилю — вкусовщина, отклоняются вежливо с указанием на правила; если замечание разумное и системное — оно становится правилом линтера (конфиг обновляется одним PR — будущее такое не пропустит).
Кто ревьюит сеньоров и архитекторов? Все — peer-ревью обязательно для каждого (исключения «лид не ревьюится» — источник и багов, и культуры двойных стандартов); на архитектурные изменения — второй опытный ревьюер или RFC-обсуждение до кода (ADR-практика) — крупные решения проходят до реализации, не на диффе.
Как ревьюить то, в чём не разбираешься? Честно: «не моя область — ревьюю читаемость и тесты, по доменной части нужен X» — частичное ревью с явной границей полезнее молчаливого LGTM; запрос эксперта по части диффа (GitHub позволяет несколько ревьюеров) — нормальная практика, не признание слабости.
Источники: Google eng-practices (code review), Conventional Comments — ссылки в шапке.