Zwei Reviewer, ein Diff, keine Überschneidung

Zwei Senior Engineers reviewen denselben Pull Request. Einer markiert einen fehlenden Null Check. Der andere entdeckt einen Race Condition im Cleanup-Path. Keiner von beiden findet beides.

Hättest du nur einen Reviewer zugewiesen, wäre einer dieser Bugs ausgeliefert worden. Das ist kein Skill-Gap. Es ist eine vorhersehbare Eigenschaft menschlicher Aufmerksamkeit, und Michael Fagan dokumentierte sie 1976 bei IBM.

Fagan maß die Defekt-Detection-Raten in IBMs Software-Pipeline. Seine Daten zeigten etwas Unbequemes: selbst erfahrene Inspektoren fanden nur einen Bruchteil der Gesamtdefekte, die die Gruppe letztendlich entdeckte. Der echte Wert lag nicht in der Expertise einer einzelnen Person. Er lag in der strukturierten Kombination mehrerer Perspektiven.

Die meisten Teams strukturieren diese Kombination heute nicht. Ein Senior Engineer überfliegt ein Diff zwischen Meetings, bemerkt einen Style-Issue, approved und geht weiter. Der nächste Reviewer macht dasselbe. Beide übersehen den Off-by-one-Fehler, der nächsten Dienstag die Produktionsdaten korrumpiert.

Fagan nannte dies das Unstructured-Review-Syndrom. Die Gruppe hat Augen, aber keinen Prozess.

Was eine Fagan Inspection tatsächlich ist

Eine Fagan Inspection ist kein Meeting, bei dem Leute zusammen Code lesen und Gefühle teilen. Es ist ein formaler Prozess mit definierten Rollen, Entry-Criteria und messbarem Output. Fagan entwarf ihn, weil unstrukturierte Reviews Zeit verschwendeten und Defekte in etwa demselben Maße durchsickern ließen wie gar kein Review.

Die Kern-Erkenntnis ist die Rollentrennung. Jeder hat genau einen Job:

  • Der Moderator leitet das Meeting und erzwingt die Regeln. Er inspectiert nicht.
  • Der Reader paraphrasiert den Code laut. Das zwingt die Gruppe, sich dem zu stellen, was der Code tatsächlich tut, nicht dem, was der Author beabsichtigt hat.
  • Der Tester denkt über Execution Paths, Boundary Conditions und Coverage-Gaps nach.
  • Der Author beantwortet Fragen, verteidigt den Code aber nicht.

Diese Trennung verhindert den häufigsten Failure Mode von Group-Review: der Author redet alle aus ihren Bedenken heraus.

Wenn der Author auch der Erklärer ist, glättet er Mehrdeutigkeiten aus. „Oh, diese Variable wird immer vom Caller gesetzt.“ Die Gruppe nickt. Niemand prüft nach. Die Reader-Rolle existiert, um diese Gewohnheit zu durchbrechen. Wenn der Reader eine Funktion nicht in einem Satz paraphrasieren kann, ist die Funktion nicht bereit zum Shippen.

Warum Checklists Intuition schlagen

Fagan führte auch Inspection-Checklists ein. Das sind keine generischen Coding-Standards, die aus einem Style-Guide kopiert wurden. Sie sind auf den spezifischen Typ des Artifacts zugeschnitten, das reviewed wird.

Eine Checklist für eine State Machine fragt: hast du jeden Transition behandelt? Eine Checklist für einen Resource Allocator fragt: ist jede Allocation auf jedem Path mit einer Deallocation gepaart?

Die Checklist existiert, weil menschliche Aufmerksamkeit lückenhaft ist. Ein Experte, der zehntausend Datenbank-Queries geschrieben hat, wird den BEGIN TRANSACTION-Block mental überspringen. Sein Gehirn autocompletet ihn als korrekt. Fagan fand heraus, dass checklist-gesteuerte Inspektoren Defekte fanden, an denen intuition-gesteuerte Reviewer vorbeigingen – nicht weil die Experten nachlässig waren, sondern weil Expertise Blind Spots schafft.

Hier ist eine lightweight Checklist für eine einzelne Python-Funktion:

CHECKLIST = [
    "Can a non-author paraphrase what this function does in one sentence?",
    "Does every execution path return or raise predictably?",
    "What happens at the minimum and maximum valid inputs?",
    "What happens at exactly one step past the boundary?",
    "Does the function mutate any argument, closure, or global state?",
    "Is every resource acquired also released on the error path?",
    "If this raises, can the caller distinguish recoverable from fatal?",
]

Das ist keine Bürokratie. Es ist eine Forcing Function für systematische Aufmerksamkeit.

Fagan teilte Inspections in vier Phasen auf, und das Meeting ist die Kürzeste

Eine echte Fagan Inspection hat vier Phasen, und das Meeting selbst ist die kürzeste.

Preparation. Jeder Inspektor reviewt das Material allein, mit der Checklist, bevor die Gruppe sich trifft. Fagan fand heraus, dass vorbereitete Inspektoren etwa doppelt so viele Defekte fanden wie diejenigen, die cold hereinkamen. Das Meeting existiert nur, um Findings zu kombinieren, nicht um sie zu generieren.

Das Meeting. Der Reader geht den Code durch. Der Tester stellt What-if-Fragen. Der Moderator hält es unter zwei Stunden. Der Author macht Notizen. Niemand fixt Code während des Meetings. Defekte werden geloggt und die Gruppe geht weiter.

Rework. Der Author fixt die geloggten Defekte allein.

Follow-up. Der Moderator verifiziert, dass jeder Defekt adressiert wurde. Große Reworks können eine zweite Inspection auslösen.

Diese Struktur fühlt sich für einen modernen Pull Request schwerfällig an. Fagan entwarf sie für Mainframe-Software, bei der ein einzelner Defekt Millionen kosten konnte. Die Prinzipien lassen sich aber noch auf kleinere Kontexte adaptieren.

Wo das Overkill wird

Fagan Inspections sind nicht kostenlos. Die Preparation-Time allein fügt signifikanten Overhead hinzu. Für einen zehnzeiligen Bugfix ist eine volle Fagan Inspection absurd. Du brauchst keine vier Personen und eine Checklist, um einen fehlenden Import zu finden.

Die Payoff-Curve ist nichtlinear. Fagans Daten legten nahe, dass Inspections sich am meisten für komplexe, high-risk Module lohnten: State Machines, Parser, Resource Manager, alles mit non-local State oder subtilen Ordering-Constraints. Für CRUD-Handler und Boilerplate-Tests ist informelles Review in Ordnung.

Der echte Fehler ist, dieselbe Review-Strategie auf jede Änderung anzuwenden. Ein Tippfehler in einer Log-Message braucht keine Fagan Inspection. Ein Distributed-Transaction-Coordinator wahrscheinlich schon.

Eine lightweight Version, die du heute nutzen kannst

Du brauchst IBMs Meeting-Kultur nicht, um den Großteil des Benefits zu bekommen. Hier ist eine lightweight Adaptation, die für moderne Teams funktioniert:

  1. Individual Review vor Group-Discussion vorschreiben. Jeder Reviewer submitted written comments, bevor irgendjemand spricht. Das verhindert, dass die erste laute Meinung dominiert.

  2. Die Reader-Rolle rotieren. Bitten einen Reviewer, die Änderung in eigenen Worten zusammenzufassen, bevor irgendjemand sie kritisiert. Wenn er das nicht kann, ist die Änderung zu groß oder zu unklar.

  3. Eine Team-Checklist aufbauen. Starte mit den sieben Fragen oben. Füge domain-spezifische Items hinzu. Überprüfe sie quartalsweise.

  4. Author und Defender trennen. Der Author beantwortet faktische Fragen. Er argumentiert nicht, dass der Code in Ordnung ist. Wenn ein Reviewer verwirrt ist, ist das Daten, keine Debatte.

  5. Defekte loggen, später fixen. Schreibe den Code während des Reviews nicht um. Logge das Issue, beende, dann fixe.

Hier ist ein einfaches Script, um eine Review-Checklist für jedes Python-Modul zu generieren:

import ast
import sys
from pathlib import Path

def generate_checklist(source_path: str) -> list[str]:
    """Generate a Fagan-style checklist from a Python module."""
    source = Path(source_path).read_text()
    tree = ast.parse(source)

    checklist = [
        f"Module {Path(source_path).name}: {len(tree.body)} top-level statements",
        "Can a non-author state the module's responsibility in one sentence?",
    ]

    for node in ast.walk(tree):
        if isinstance(node, ast.FunctionDef):
            checklist.append(
                f"Function '{node.name}': does every path return or raise?"
            )
            if any(isinstance(n, ast.Try) for n in ast.walk(node)):
                checklist.append(
                    f"Function '{node.name}': is every exception handled explicitly?"
                )

    return checklist

if __name__ == "__main__":
    for item in generate_checklist(sys.argv[1]):
        print(f"[ ] {item}")

Starte es so:

python inspection_checklist.py src/transaction.py

Es wird deine Bugs nicht finden. Es zwingt dich, an den richtigen Stellen hinzuschauen.

Schlauere Leute einzustellen, wird kein Process-Problem beheben

Fagans Forschung ist fast fünfzig Jahre alt, aber der Befund hat sich nicht geändert. Einzelne Reviewer sind inkonsistent. Gruppen sind auch inkonsistent, es sei denn, du strukturierst sie. Die Varianz zwischen Reviewern ist kein Problem, das man eliminieren muss. Es ist eine Ressource, die man organisieren muss.

Das nächste Mal, wenn ein Reviewer einen Bug findet, den ein anderer übersehen hat, frag nicht, wer besser ist. Frag, ob dein Prozess strukturiert genug ist, um zu kombinieren, was beide sehen. Fagan hat es bereits versucht, sich herauszuhiren. Es funktioniert nicht.

FAQ

Was ist eine Fagan Inspection?

Eine Fagan Inspection ist ein formaler, strukturierter Code-Review-Prozess, der von Michael Fagan 1976 bei IBM entwickelt wurde. Er verwendet definierte Rollen (Moderator, Reader, Tester, Author), Preparation-Requirements und Checklists, um die Defekt-Detection in Software-Artefakten zu maximieren.

Warum finden verschiedene Reviewer verschiedene Bugs?

Menschliche Aufmerksamkeit ist selektiv. Experten entwickeln mentale Shortcuts, die es ihnen ermöglichen, Code schnell zu lesen, aber dieselben Shortcuts schaffen Blind Spots. Verschiedene Reviewer haben verschiedene Backgrounds und kognitive Patterns, daher überlappen sich ihre Blind Spots nicht perfekt. Fagans Forschung zeigte, dass der Wert von Inspection in der Kombination mehrerer unvollständiger Perspektiven liegt, nicht darin, einen perfekten Reviewer zu finden.

Werden Fagan Inspections heute noch verwendet?

Der volle formale Prozess ist außerhalb sicherheitskritischer Industrien wie Luft- und Raumfahrt und Medizintechnik selten. Die zugrunde liegenden Prinzipien – individuelle Preparation, Rollentrennung und checklist-gesteuertes Review – werden jedoch zunehmend von high-performing Software-Teams adaptiert. Die Kernideen beeinflussten auch moderne Praktiken wie strukturierte Walkthroughs und formale Technical Reviews.

Wann lohnt sich der Overhead einer vollen Fagan Inspection?

Für Module, bei denen ein Defekt schwerwiegende Folgen hat: Distributed-Consensus-Logik, Security Boundaries, Resource Lifecycles und State Machines. Für Routine-Änderungen sind lightweight Adaptationen normalerweise ausreichend. Passe die Review-Rigor dem tatsächlichen Risk an, nicht denselben Prozess auf jedes Diff.