Ваше code review, вероятно, не работает

Большинство code review находит от 15 до 30 процентов дефектов, которые должны были обнаружить. Это не догадка. IBM измерила это в 1970-х, и исследования в AT&T, HP и Microsoft десятилетие за десятилетием подтверждали тот же диапазон.

Неформальный review дёшев, асинхронен и социально приемлем. Он также в большинстве случаев неэффективен при поиске багов. Инженеры читают слишком быстро, пропускают error paths и избегают указывать на реальные проблемы, потому что никто не хочет быть тем, кто блокирует merge.

Существует альтернатива, которая стабильно демонстрирует показатели устранения дефектов от 60 до 90 процентов. Она была изобретена в IBM в 1976 году Майклом Фаганом. Она не требует инструментов, ИИ и бюджета. Она требует того, что большинство инженерных команд отказываются давать: структуры.

Что такое Fagan inspection?

Fagan inspection — это формально определённый многоэтапный процесс review с конкретными ролями, временны́ми лимитами, критериями входа и чек-листами. В отличие от типичного pull request review, это не разговор между автором и рецензентом. Это структурированное совещание с модератором, reader, инспекторами и автором.

Автор в основном молчит. Совещание строго timeboxed. И единственная цель — найти дефекты.

Процесс состоит из шести шагов:

  1. Planning. Модератор выбирает материал, проверяет критерии входа, назначает роли и планирует совещание. Критерии входа существуют не зря. Не инспектируется черновик. Документ должен быть полным, компилируемым и протестированным, прежде чем он заслужит право занимать время четырёх человек.

  2. Overview. Опционально. Автор объясняет контекст, если инспекторы не знакомы с доменом.

  3. Preparation. Каждый инспектор просматривает материал в одиночку до совещания. Это не обсуждается. Нельзя приходить без подготовки. Инспекторы используют чек-листы, адаптированные к распространённым типам дефектов, и приватно аннотируют issue.

  4. Inspection. Само совещание. Reader, который не писал код, проходит его построчно и перефразирует вслух. Инспекторы поднимают issue, когда замечают несоответствия. Автор слушает. Никто не предлагает fixes. Модератор соблюдает временны́е лимиты и удерживает совещание в фокусе исключительно на идентификации дефектов.

  5. Rework. Автор исправляет дефекты.

  6. Follow-up. Модератор проверяет, что каждый дефект был устранён. Если было найдено слишком много дефектов, проводится reinspection.

Четыре роли обеспечивают честность процесса. Модератор планирует и контролирует. Автор создал работу и отвечает на вопросы только по запросу. Reader перефразирует код во время совещания, заставляя группу работать с ним медленнее и внимательнее. Инспекторы, обычно от двух до четырёх человек, находят дефекты.

Почему неформальный review терпит неудачу там, где Fagan inspections преуспевают

Разница не в таланте. Она в дизайне процесса.

При типичном pull request review рецензент читает diff в браузере, пролистывает happy path, оставляет несколько комментариев и одобряет. Нет времени на подготовку. Нет чек-листа. Нет механизма, который заставил бы рецензента изучить error handling или boundary conditions. Социальная динамика поощряет скорость и вежливость, а не тщательность.

Fagan inspections инвертируют эти стимулы.

Индивидуальная подготовка означает, что каждый инспектор действительно прочитал код до начала совещания. Перефразировка reader заставляет группу обрабатывать код со скоростью осмысления, а не со скоростью беглого просмотра. Чек-листы направляют внимание на известные категории дефектов, а не на то, что бросается в глаза. Временно́е давление не даёт совещанию уйти в дизайн-дебаты. А разделение поиска дефектов и их исправления не позволяет группе зациклиться на первом же предложенном решении.

В результате Fagan inspections находят большинство дефектов до того, как они попадут в testing или production.

Стоимость сосредоточена в начале в person-hours.

Реальный trade-off: person-hours vs. ускользнувшие дефекты

Вот почему большинство команд не используют Fagan inspections.

Одна inspection требует от четырёх до шести человек в комнате на срок до двух часов для review примерно 250 строк кода. Это от 8 до 12 person-hours для небольшого изменения. В современном CI/CD-воркфлоу, где команды деплоят несколько раз в день, это выглядит абсурдно.

Процесс также кажется бюрократичным. Критерии входа, формальные роли, печатные чек-листы, верификация follow-up. Большинство инженеров возненавидят его по принципу. И он не масштабируется на большие diff. Рефакторинг в две тысячи строк потребовал бы восьми отдельных inspection-совещаний.

Но расчёт меняется, если смотреть на общую стоимость, а не стоимость совещания.

Исходные данные IBM показали, что нахождение и исправление дефекта в ходе inspection стоило примерно в десять раз меньше, чем нахождение и исправление того же дефекта в ходе testing. Если он ускользал в production, соотношение вырастало до двадцати или тридцати к одному.

Так да, inspection дорога. Но она всё равно дешевле, чем отладка production-инцидентов, сжигание sprint capacity на реактивные fixes и потеря доверия клиентов.

Проблема в том, что экономия невидима. Нельзя измерить баг, который предотвратили. Стоимость совещания немедленна и очевидна. Вот почему неформальный review побеждает в большинстве организаций. Он оптимизирует видимую скорость в ущерб невидимому качеству.

Запуск облегчённой Fagan inspection в 2026 году

Не нужно принимать полный церемониал. Большинство команд могут получить семьдесят процентов пользы при двадцати процентах overhead, сохранив core mechanics и отбросив paperwork.

Вот практическая последовательность:

Требуйте индивидуальной подготовки перед любым синхронным review. Если вы не читали код, вы не участвуете.

Назначьте reader, который не писал код, чтобы он вслух прошёлся по логике. Не позволяйте автору вести процесс. Перефразировка заставляет группу обработать каждую ветку.

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

Timebox девяносто минут. Заканчивайте вовремя, даже если не закончили. Назначьте вторую сессию, а не позволяйте усталости разрушить качество.

Держите автора пассивным. Они отвечают только на уточняющие вопросы. Без защиты design-решений.

Фиксируйте дефекты, а не решения. Исправляйте дефекты после совещания.

Чтобы конкретизировать, вот небольшой Python-скрипт, который планирует inspection, оценивает время и выводит ролевые чек-листы:

#!/usr/bin/env python3
"""
Plan a Fagan-style inspection: estimate time and emit checklists.
"""

import argparse


def count_lines(filepath):
    """Count non-blank lines."""
    try:
        with open(filepath, "r") as f:
            return sum(1 for line in f if line.strip())
    except Exception:
        return 0


def plan_inspection(files, rate=125):
    """
    rate: reviewable lines per hour. Fagan recommended 100-125 for code.
    """
    total = sum(count_lines(f) for f in files)
    hours = total / rate
    minutes = hours * 60

    print(f"Total reviewable lines: {total}")
    print(f"At {rate} lines/hour, schedule: {hours:.1f} hours ({minutes:.0f} min)")

    if hours > 2:
        sessions = int(hours / 2) + 1
        print(f"WARNING: exceeds 2-hour limit. Split into {sessions} sessions.")

    print("\n--- ROLE: Reader ---")
    print("Paraphrase each block aloud. Do not just read variable names.")
    print("Pause at every conditional, loop boundary, and API call.")

    print("\n--- ROLE: Inspector ---")
    checklist = [
        "Off-by-one in loops and array or slice access",
        "Null, None, or undefined dereferences",
        "Resource leaks: files, connections, locks, contexts",
        "Error paths: are they handled, returned, and tested?",
        "Return values: are they checked before use?",
        "Shared mutable state and thread safety",
        "Boundary conditions and input validation",
        "Invariant violations: what should stay true, and does it?",
    ]
    for item in checklist:
        print(f"  [ ] {item}")

    print("\n--- ROLE: Moderator ---")
    print("Start on time. End on time.")
    print("No design debates. No solution proposals.")
    print("Record each defect with: file, line, severity, type.")


if __name__ == "__main__":
    parser = argparse.ArgumentParser(description="Plan a Fagan inspection")
    parser.add_argument("files", nargs="+", help="Source files to inspect")
    parser.add_argument("--rate", type=int, default=125, help="Lines per hour")
    args = parser.parse_args()

    plan_inspection(args.files, args.rate)

Сохраните как inspect.py, запустите python inspect.py src/auth.py src/orders.py, и у вас будет оценка времени и чек-лист.

Часто задаваемые вопросы

Что такое Fagan inspection?

Fagan inspection — это структурированный шестиэтапный процесс review с определёнными ролями, критериями входа и чек-листами. Он был разработан Майклом Фаганом в IBM в 1976 году для поиска дефектов в программных работах до testing.

Чем Fagan inspection отличается от pull request review?

Pull request review обычно асинхронен, неформален и управляется автором. Fagan inspection — это синхронное совещание с назначенными ролями, обязательной индивидуальной подготовкой, строгими временны́ми лимитами и правилом, согласно которому автор молчит, пока другие находят дефекты.

Почему Fagan inspections не получили более широкого распространения?

Они дороги в person-hours, кажутся бюрократичными современным командам и плохо масштабируются на крупные и частые изменения. Стоимость видима и немедленна. Предотвращённые дефекты невидимы.

Могут ли Fagan inspections работать в agile или CI/CD-среде?

Да, но с модификациями. Большинство команд используют облегчённые версии: обязательная индивидуальная подготовка, reader, который перефразирует, чек-лист и строгий timebox. Полный формальный процесс обычно резервируется для критических или высокорискованных модулей.

Попробуйте на одном модуле

Вам не нужно переписывать свой процесс. Выберите один модуль, в котором за последний месяц были ускользнувшие дефекты. Соберите трёх инженеров, которые его не писали. Дайте им код и чек-лист за двадцать четыре часа до совещания. Запланируйте девяносто минут. Назначьте reader. Заставьте автора слушать.

Измерьте, что вы найдёте. Затем решите, стоило ли совещание дороже, чем обошлись бы баги.

Если вам нужны исходные данные, статья Фагана 1976 года «Design and Code Inspections to Reduce Errors in Program Development» по-прежнему остаётся лучшей справкой. Ей пятьдесят лет, а большинство команд всё ещё не догнали.