Die meisten Code Reviews finden 20 % der Defekte. Fagan Inspections finden 90 %.

Dein Code Review ist wahrscheinlich kaputt

Die meisten Code Reviews finden zwischen 15 und 30 Prozent der Defekte, die sie finden sollten. Das ist keine Vermutung. IBM hat das in den 1970ern gemessen, und Studien bei AT&T, HP und Microsoft haben dieselbe Spanne Jahrzehnt für Jahrzehnt bestätigt.

Informelles Review ist billig, asynchron und sozial akzeptabel. Es ist auch größtenteils ineffektiv beim Finden von Bugs. Ingenieure lesen zu schnell, überspringen die Error Paths und vermeiden es, auf echte Probleme hinzuweisen, weil niemand die Person sein will, die den Merge blockiert.

Es gibt eine Alternative, die konstant Entfernungsraten von 60 bis 90 Prozent meldet. Sie wurde 1976 bei IBM von Michael Fagan erfunden. Sie erfordert keine Tools, keine KI und kein Budget. Sie erfordert etwas, das die meisten Engineering-Teams nicht geben wollen: Struktur.

Was ist eine Fagan Inspection?

Eine Fagan Inspection ist ein formal definierter, mehrstufiger Review-Prozess mit spezifischen Rollen, Time Limits, Entry Criteria und Checklisten. Im Gegensatz zu einem typischen Pull-Request-Review ist es kein Gespräch zwischen Autor und Reviewer. Es ist ein strukturiertes Meeting mit einem Moderator, einem Reader, Inspectors und dem Autor.

Der Autor ist größtenteils still. Das Meeting ist streng timeboxed. Und das einzige Ziel ist, Defekte zu finden.

Der Prozess folgt sechs Schritten:

1. Planning. Der Moderator wählt das Material aus, verifiziert die Entry Criteria, weist Rollen zu und plant das Meeting. Entry Criteria existieren aus einem Grund. Man inspiziert keinen Entwurf. Das Dokument muss vollständig, compilierbar und getestet sein, bevor es das Recht verdient, vier Personen Zeit zu kosten.

2. Overview. Optional. Der Autor erklärt Kontext, wenn die Inspectors mit der Domain nicht vertraut sind.

3. Preparation. Jeder Inspector reviewt das Material allein vor dem Meeting. Das ist non-negotiable. Man erscheint nicht unvorbereitet. Inspectors verwenden Checklisten, die auf häufige Defekttypen zugeschnitten sind, und markieren Issues privat.

4. Inspection. Das Meeting selbst. Der Reader, der den Code nicht geschrieben hat, geht ihn Zeile für Zeile durch und paraphrasiert laut. Inspectors melden Issues, wenn sie Diskrepanzen entdecken. Der Autor hört zu. Niemand schlägt Fixes vor. Der Moderator setzt Time Limits durch und hält das Meeting auf Defektidentifikation fokussiert.

5. Rework. Der Autor behebt die Defekte.

6. Follow-up. Der Moderator verifiziert, dass jeder Defekt behandelt wurde. Wenn zu viele Defekte gefunden wurden, findet eine Reinspection statt.

Vier Rollen halten den Prozess ehrlich. Der Moderator plant und kontrolliert. Der Autor hat die Arbeit erstellt und beantwortet Fragen nur wenn gefragt. Der Reader paraphrasiert den Code während des Meetings und erzwingt so eine langsamere, sorgfältigere Erfassung. Die Inspectors, normalerweise zwei bis vier Personen, finden die Defekte.

Warum informelles Review dort scheitert, wo Fagan Inspections erfolgreich sind

Der Unterschied ist nicht Talent. Es ist Prozessdesign.

Bei einem typischen Pull-Request-Review liest der Reviewer den Diff im Browser, überfliegt den Happy Path, hinterlässt ein paar Kommentare und approvt. Es gibt keine Vorbereitungszeit. Es gibt keine Checkliste. Es gibt keinen Mechanismus, der den Reviewer zwingt, das Error Handling oder die Boundary Conditions zu untersuchen. Die sozialen Dynamiken belohnen Geschwindigkeit und Höflichkeit, nicht Gründlichkeit.

Fagan Inspections kehren diese Anreize um.

Individuelle Vorbereitung bedeutet, dass jeder Inspector den Code tatsächlich gelesen hat, bevor das Meeting beginnt. Die Paraphrase des Readers zwingt die Gruppe, den Code in Comprehension-Geschwindigkeit statt in Skimming-Geschwindigkeit zu verarbeiten. Checklisten lenken die Aufmerksamkeit auf bekannte Defektkategorien statt auf das, was gerade auffällt. Time Pressure verhindert, dass das Meeting in Design-Debatten abdriftet. Und die Trennung von Defektfindung und Defektbehebung verhindert, dass die Gruppe auf der ersten Lösung verankert, die jemand vorschlägt.

Das Ergebnis ist, dass Fagan Inspections die meisten Defekte finden, bevor sie Testing oder Production erreichen.

Die Kosten sind vornherein in Person-Hours investiert.

Der echte Trade-Off: Person-Hours vs. Defekt-Escape

Hier ist, warum die meisten Teams keine Fagan Inspections verwenden.

Eine einzelne Inspection erfordert vier bis sechs Personen in einem Raum für bis zu zwei Stunden, um ungefähr 250 Zeilen Code zu reviewen. Das sind 8 bis 12 Person-Hours für eine kleine Änderung. In einem modernen CI/CD-Workflow, in dem Teams mehrmals am Tag deployen, sieht das absurd aus.

Der Prozess fühlt sich auch bürokratisch an. Entry Criteria, formale Rollen, gedruckte Checklists, Follow-up-Verifizierung. Die meisten Ingenieure werden ihn aus Prinzip hassen. Und er skaliert nicht auf große Diffs. Ein zweitausendzeiliger Refactor würde acht separate Inspection-Meetings erfordern.

Aber die Rechnung ändert sich, wenn man sich die Gesamtkosten statt der Meeting-Kosten ansieht.

IBMs ursprüngliche Daten zeigten, dass das Finden und Beheben eines Defekts während der Inspection etwa ein Zehntel dessen kostete, was es kostete, denselben Defekt während des Testings zu finden und zu beheben. Wenn er in Production escapte, wuchs das Verhältnis auf zwanzig oder dreißig zu eins.

Ja, die Inspection ist teuer. Sie ist immer noch billiger als Debugging von Production-Incidents, Verbrauchen von Sprint-Kapazität auf reaktive Fixes und Verlieren von Kundenvertrauen.

Das Problem ist, dass die Einsparungen unsichtbar sind. Man kann den Bug nicht messen, den man verhindert hat. Die Kosten des Meetings sind sofort und offensichtlich. Deshalb gewinnt informelles Review in den meisten Organisationen. Es optimiert für sichtbare Geschwindigkeit über unsichtbare Qualität.

Eine leichtgewichtige Fagan Inspection in 2026 durchführen

Man muss nicht die volle Ceremony übernehmen. Die meisten Teams können siebzig Prozent des Nutzens mit zwanzig Prozent des Overheads erhalten, indem sie die Core Mechanics beibehalten und den Paperwork weglassen.

Hier ist eine praktische Sequenz:

Individuelle Vorbereitung vor jedem synchronen Review erforderlich. Wenn du den Code nicht gelesen hast, nimmst du nicht teil.

Weise einen Reader zu, der den Code nicht geschrieben hat, um die Logik laut durchzugehen. Lass den Autor nicht führen. Paraphrasieren zwingt die Gruppe, jeden Branch zu verarbeiten.

Verwende eine Checklist, die auf die häufigsten Defekttypen deines Teams zugeschnitten ist. Beginne mit der Liste unten und füge Items hinzu, während du von escapten Defekten lernst.

Timebox auf neunzig Minuten. Beende pünktlich, auch wenn du nicht fertig bist. Plane eine zweite Session, anstatt zu zulassen, dass Müdigkeit die Qualität zerstört.

Halte den Autor passiv. Sie beantworten nur Klärungsfragen. Kein Verteidigen von Design-Entscheidungen.

Notiere Defekte, nicht Lösungen. Behebe die Defekte nach dem Meeting.

Um das konkret zu machen, hier ist ein kleines Python-Skript, das eine Inspection plant, die Zeit schätzt und rollenspezifische Checklists ausgibt:

#!/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)

Speichere es als inspect.py, führe python inspect.py src/auth.py src/orders.py aus, und du hast eine Zeitschätzung und eine Checklist.

Häufig gestellte Fragen

Was ist eine Fagan Inspection?

Eine Fagan Inspection ist ein strukturierter, sechsstufiger Review-Prozess mit definierten Rollen, Entry Criteria und Checklists. Sie wurde von Michael Fagan bei IBM in 1976 entwickelt, um Defekte in Software-Arbeitsprodukten vor dem Testing zu finden.

Wie unterscheidet sich eine Fagan Inspection von einem Pull-Request-Review?

Ein Pull-Request-Review ist typischerweise asynchron, informell und vom Autor getrieben. Eine Fagan Inspection ist ein synchrones Meeting mit zugewiesenen Rollen, obligatorischer individueller Vorbereitung, strengen Time Limits und einer Regel, dass der Autor still bleibt, während andere Defekte finden.

Warum sind Fagan Inspections nicht verbreiteter?

Sie sind teuer in Person-Hours, fühlen sich für moderne Teams bürokratisch an und skalieren nicht gut auf große, häufige Änderungen. Die Kosten sind sichtbar und sofort. Die verhinderten Defekte sind unsichtbar.

Können Fagan Inspections in einer agilen oder CI/CD-Umgebung funktionieren?

Ja, aber mit Modifikationen. Die meisten Teams verwenden leichtgewichtige Versionen: obligatorische individuelle Vorbereitung, ein Reader, der paraphrasiert, eine Checklist und eine strenge Timebox. Der vollständige formale Prozess ist normalerweise für kritische oder hochriskante Module reserviert.

Probiere es an einem Modul aus

Du musst deinen Prozess nicht umschreiben. Wähle ein Modul, das in den letzten Monat escapte Defekte hatte. Versammle drei Ingenieure, die es nicht geschrieben haben. Gib ihnen den Code und eine Checklist vierundzwanzig Stunden im Voraus. Plane neunzig Minuten. Weise einen Reader zu. Lass den Autor zuhören.

Miss, was du findest. Dann entscheide, ob das Meeting mehr gekostet hat als die Bugs gekostet hätten.

Wenn du die Originaldaten willst, ist Fagans Paper von 1976 “Design and Code Inspections to Reduce Errors in Program Development” immer noch die beste Referenz. Es ist fünfzig Jahre alt, und die meisten Teams haben immer noch nicht aufgeholt.