Pull-Request-Reviews finden 15–30 % der Defekte. Die Daten sagen das seit 50 Jahren.

Die Zahl, über die niemand reden will

Informelle Code-Reviews finden zwischen 15 und 30 Prozent der Defekte, die im überprüften Code vorhanden sind. Das ist keine Meinung. Es ist ein Befund, der über vier Jahrzehnte, mehrere Unternehmen und Dutzende Studien hinweg repliziert wurde.

Michael Fagan dokumentierte es 1976 bei IBM. Eine Studie von 1987 bei AT&T Bell Labs fand 20 Prozent. Eine HP-Studie von 1996 fand 25 Prozent. Ein Microsoft Research Paper von 2013 zu modernem Code Review fand ungefähr denselben Bereich. Die Tools änderten sich von Lochkarten zu GitHub, aber die menschliche Leistungskurve bewegte sich nicht.

Wenn Ihr Team denkt, dass Pull-Request-Review Ihr Qualitätsanker ist, sagt Ihnen die Daten, dass Sie etwa jeden vierten Bug finden. Die anderen drei gehen in Produktion.

Woher die Zahlen kommen

Fagans ursprüngliche Methodik war simpel und brutal. Er injizierte bekannte Defekte in Code, führte den Review-Prozess durch und zählte, wie viele die Reviewer fanden. Dann verglich er das mit den Gesamtdefekten, die das Team schließlich durch Tests, Produktionsvorfälle und Kundenberichte fand. Das Verhältnis von Gefunden-im-Review zu Gesamtdefekten wurde zur Removal Rate.

Der entscheidende Einblick ist, dass der Nenner wichtig ist. Ein Review, der zehn Defekte findet, klingt gut, bis man erfährt, dass es fünfzig in der Datei gab. Fagan maß den vollen Nenner. Die meisten Teams heute nicht.

Nachfolgende Studien verwendeten ähnliche Designs. Forscher setzten Defekte ein, verglichen Review-Typen oder verfolgten Defekte rückwärts von der Produktion, um zu sehen, wo sie hätten gefunden werden können. Die Ergebnisse gruppieren sich eng:

Review-Typ	Defect Removal Rate	Wichtige Studien
Kein Review	0%	Baseline
Informell / PR-Review	15-30%	Fagan 1976, Porter 1995, Microsoft 2013
Strukturierter Walkthrough	30-50%	Yourdon 1979, Weller 1993
Fagan-Inspection	60-90%	Fagan 1976, Russell 1991, NASA 2002

Die Lücke zwischen informellem und strukturiertem Review ist nicht klein. Es ist ein 3-facher Unterschied in der Defekt-Escape-Rate.

Warum PR-Review so schlecht abschneidet

Das Problem ist nicht, dass Reviewer schlecht in ihrem Job sind. Das Problem ist, dass Pull-Request-Review nicht darauf ausgelegt ist, Defekte zu finden. Es ist darauf ausgelegt, dass zwei Personen zustimmen, dass Code gemergt werden kann.

Hier ist, was in einem typischen PR-Review tatsächlich passiert. Der Reviewer öffnet den Diff. Er liest die Zusammenfassung, scannt die Hinzufügungen, prüft, ob die Tests bestehen, und sucht nach offensichtlich Falschem. Das dauert fünf bis fünfzehn Minuten. Dann approven sie.

Der Prozess ist auf Geschwindigkeit optimiert, nicht auf Gründlichkeit. Es gibt keine Vorbereitungszeit. Der Reviewer hat den umgebenden Code nicht gelesen, den Datenfluss nicht verfolgt oder ein mentales Modell der Änderung aufgebaut. Er reagiert auf einen Diff auf einem Bildschirm, und menschliche Gehirne sind schlecht darin, Bugs in diesem Format zu finden.

Eine Studie von Bacchelli und Bird bei Microsoft aus dem Jahr 2015 fand, dass die häufigsten Review-Kommentar-Kategorien gar nicht defektbezogen waren. Die Top-Kategorien waren Fragen zur Absicht, Bitte um Klärung und Verbesserungsvorschläge. Tatsächliche Defektfunde waren eine Minderheit der Kommentare. Das Tool fungierte als Kommunikationskanal, nicht als Qualitäts-Gate.

Das ist in Ordnung, wenn Sie wissen, was das Tool tut. Es ist gefährlich, wenn Sie denken, es tut etwas anderes.

Was strukturiertes Review anders macht

Fagan-Inspections und andere strukturierte Review-Methoden erreichen höhere Removal Rates, indem sie das Prozessdesign ändern, nicht die Menschen.

Der größte Hebel ist die individuelle Vorbereitung. In einer Fagan-Inspection verbringt jeder Reviewer fokussierte Zeit mit dem Material, bevor es eine Gruppendiskussion gibt. Fagan fand, dass vorbereitete Inspektoren ungefähr doppelt so viele Defekte fanden wie diejenigen, die kalt hereinkamen. Das PR-Modell ist standardmäßig das Kalt-hereinkommen-Modell.

Der zweite Hebel ist das Tempo. Fagan empfahl 100 bis 125 Codezeilen pro Review-Stunde. Die meisten PR-Reviewer verarbeiten das zehnfache dieser Rate. Geschwindigkeit tötet die Erkennung. Ihr Gehirn füllt erwartete Muster aus, anstatt zu lesen, was tatsächlich da ist.

Der dritte Hebel ist der Fokus. Fagan-Meetings haben einen einzigen Zweck: Defekte loggen. Keine Design-Debatten. Keine Lösungsvorschläge. Keine Style-Diskussionen. PR-Threads driften routinemäßig in Architekturmeinungen ab, die denselben kognitiven Budget verbrauchen, das eine Null-Dereference hätte finden können.

Der vierte Hebel ist die Leser-Rolle. Wenn jemand, der den Code nicht geschrieben hat, ihn laut paraphrasiert, zwingt er die Gruppe, auf Verständnisgeschwindigkeit statt auf Scan-Geschwindigkeit zu verarbeiten. Ein Diff auf einem Bildschirm lässt Ihre Augen die langweiligen Teile überspringen. Eine sprechende Person überspringt nicht.

Das Kostenargument ist verkehrt herum

Der übliche Einwand gegen strukturiertes Review ist der Kostenaufwand. Eine Fagan-Inspection verbraucht vier bis sechs Personenstunden für ein paar hundert Codezeilen. Ein PR-Review verbraucht fünfzehn Minuten der Zeit einer Person. Die Rechnung sieht offensichtlich aus.

Sie ist offensichtlich, und sie ist falsch.

Fagan maß auch die Kosten, Defekte in verschiedenen Phasen zu finden. Ein Defekt, der während der Inspection gefunden wurde, kostete etwa ein Zehntel dessen, was es kostete, ihn während des Tests zu finden. Wenn er in die Produktion entkam, wuchs das Verhältnis auf zwanzig oder dreißig zu eins. Die NASA-Studie von 2002 fand, dass jede in Inspection verbrachte Stunde durchschnittlich 33 Stunden Wartungsarbeit später verhinderte.

Die Einsparungen sind unsichtbar. Sie können den Bug, den Sie verhindert haben, nicht messen. Die Kosten des Meetings sind sofort und offensichtlich. Deshalb optimieren Organisationen für sichtbare Geschwindigkeit statt für unsichtbare Qualität, selbst wenn die Daten sagen, dass sie am Ende mehr kosten.

Ein datengetriebener Mittelweg

Sie brauchen nicht die Meeting-Kultur von IBM, um den Großteil des Nutzens zu erhalten. Sie müssen sich die Prozessmerkmale leihen, die die Zahl tatsächlich bewegen, und diejenigen fallen lassen, die es nicht tun.

Hier ist, was die Daten sagen, was wichtig ist:

1. Vorbereitungszeit. Verlangen Sie von Reviewern, Zeit mit dem Code zu verbringen, bevor sie kommentieren. Selbst zehn Minuten fokussiertes Lesen schlagen ein Überfliegen.

2. Tempolimits. Für kritische Dateien, erzwingen Sie eine maximale Review-Geschwindigkeit. Wenn ein Reviewer eine 500-Zeilen-Änderung in fünf Minuten approvt, sind das Daten, nicht Gründlichkeit.

3. Defekt-only-Fokus. Trennen Sie Style- und Architektur-Feedback von der Defektsuche. Verwenden Sie automatische Formatter für Ersteres. Reservieren Sie menschliche Aufmerksamkeit für Letzteres.

4. Checklisten. Fagan fand, dass checklistengesteuerte Reviewer Defekte fanden, an denen intuitiv gesteuerte Reviewer vorbeigingen. Die Checkliste existiert, weil Expertise blinde Flecken schafft.

Hier ist ein leichtgewichtiges Skript, das die Review-Tiefe aus der Git-Historie misst. Es schätzt, ob ein Review genug Zeit hatte, um gründlich zu sein:

#!/usr/bin/env python3
"""Estimate review depth from git history."""

import subprocess
import sys
from datetime import datetime, timezone


def get_commit_info(commit_hash: str) -> dict:
    """Return author, committer, and timestamps for a commit."""
    fmt = "%H|%an|%cn|%ad|%cd"
    result = subprocess.run(
        ["git", "log", "-1", f"--format={fmt}", commit_hash],
        capture_output=True,
        text=True,
        check=True,
    )
    parts = result.stdout.strip().split("|")
    return {
        "hash": parts[0],
        "author": parts[1],
        "committer": parts[2],
        "author_date": datetime.strptime(parts[3], "%a %b %d %H:%M:%S %Y %z"),
        "commit_date": datetime.strptime(parts[4], "%a %b %d %H:%M:%S %Y %z"),
    }


def get_lines_changed(commit_hash: str) -> int:
    """Count total lines added + deleted in a commit."""
    result = subprocess.run(
        ["git", "diff", f"{commit_hash}^", commit_hash, "--stat"],
        capture_output=True,
        text=True,
        check=True,
    )
    # Last line of --stat contains totals like "3 files changed, 42 insertions(+), 7 deletions(-)"
    for line in reversed(result.stdout.strip().splitlines()):
        line = line.strip()
        if "insertions" in line or "deletions" in line:
            # Extract numbers roughly
            parts = line.split(",")
            total = 0
            for part in parts:
                digits = "".join(ch for ch in part if ch.isdigit())
                if digits:
                    total += int(digits)
            return total
    return 0


def estimate_review_depth(commit_hash: str) -> dict:
    """Estimate whether a commit had time for thorough review.

    Returns lines changed, time between author and commit dates
    (a rough proxy for review duration), and a verdict.
    """
    info = get_commit_info(commit_hash)
    lines = get_lines_changed(commit_hash)

    # Time between author date and commit date is a proxy for review time
    # In many workflows, commit date reflects when the merge happened
    review_seconds = (info["commit_date"] - info["author_date"]).total_seconds()
    review_hours = review_seconds / 3600

    # Fagan recommended 100-125 lines/hour for thorough review
    fagan_rate = 125
    needed_hours = lines / fagan_rate if lines else 0

    verdict = "insufficient"
    if review_hours >= needed_hours:
        verdict = "adequate"
    if review_hours >= needed_hours * 2:
        verdict = "thorough"

    return {
        "hash": commit_hash[:8],
        "lines": lines,
        "review_hours": round(review_hours, 2),
        "needed_hours": round(needed_hours, 2),
        "verdict": verdict,
    }


if __name__ == "__main__":
    commit = sys.argv[1] if len(sys.argv) > 1 else "HEAD"
    result = estimate_review_depth(commit)
    print(f"Commit:       {result['hash']}")
    print(f"Lines:        {result['lines']}")
    print(f"Review time:  {result['review_hours']} hours")
    print(f"Fagan time:   {result['needed_hours']} hours")
    print(f"Verdict:      {result['verdict']}")

Speichern Sie es als review_depth.py und führen Sie es aus:

python review_depth.py abc1234

Die Ausgabe wird Ihnen sagen, ob ein Commit genug Review-Zeit hatte, um nach Fagans Standard gründlich zu sein. Die meisten Commits werden insufficient sagen. Das ist der Punkt. Die Daten haben uns das seit Jahrzehnten gesagt, und wir bauen schnellere Pipelines statt bessere.

Was das für Ihr Team bedeutet

Pull-Request-Review ist nicht nutzlos. Es baut gemeinsamen Kontext auf, verbreitet Wissen und fängt offensichtliche Fehler. Aber die Daten sind klar darüber, was es nicht tut. Es fängt nicht die meisten Defekte.

Wenn Ihre Qualitätsstrategie auf PR-Review als primären Filter angewiesen ist, filtern Sie mit einem Sieb. Die 15-30%-Removal-Rate ist kein Versagen Ihrer Reviewer. Es ist eine Eigenschaft des Prozesses.

Die Teams, die diese Zahl schlagen, stellen nicht klügere Leute ein. Sie ändern den Prozess. Sie fügen Vorbereitungszeit hinzu, erzwingen Tempolimits, trennen Defektfinden von Design-Diskussionen und verwenden Checklisten, um Aufmerksamkeit dorthin zu lenken, wo Intuition sie verpasst.

Sie brauchen keine vollständige Fagan-Inspection für jeden Diff. Sie müssen wissen, was Ihr aktueller Prozess tatsächlich erreicht, und aufhören, so zu tun, als würde er mehr erreichen.

FAQ

Was sagen die Daten über die Effektivität von Pull-Request-Review?

Mehrere Studien bei IBM, AT&T, HP und Microsoft finden konsistent, dass informelle Code-Reviews 15-30% der im Code vorhandenen Defekte finden. Dieser Bereich ist von den 1970er Jahren bis zur modernen Forschung zu GitHub-basierten Workflows stabil geblieben.

Warum finden Pull-Request-Reviews so wenige Defekte?

PR-Review ist auf Geschwindigkeit und Merge-Approval optimiert, nicht auf systematische Defekterkennung. Reviewer verbringen typischerweise 5-15 Minuten pro Review, haben keine Vorbereitungszeit, verarbeiten Code mit dem 10-fachen der Rate, die die Forschung empfiehlt, und das Format ermutigt zum Überfliegen statt zur tiefen Analyse.

Wie viel besser sind strukturierte Reviews wie Fagan-Inspections?

Fagan-Inspections berichten konsistent von 60-90%igen Defect Removal Rates, also ungefähr 3-4x besser als informelle Reviews. Der Unterschied kommt von individueller Vorbereitung, erzwungenen Tempolimits, Rollentrennung, checklistengesteuertem Fokus und Meetings, die Defekte loggen statt Lösungen zu debattieren.

Was ist der billigste Weg, die PR-Review-Effektivität zu verbessern?

Verlangen Sie individuelle Vorbereitung vor dem Kommentieren, verwenden Sie Checklisten, die auf die häufigsten Defekttypen Ihres Teams zugeschnitten sind, trennen Sie Style-Feedback von der Defektsuche und begrenzen Sie die Review-Geschwindigkeit für kritische Dateien. Selbst kleine Änderungen an Vorbereitung und Fokus können die Zahl signifikant bewegen, ohne Meeting-Overhead hinzuzufügen.

Wie messe ich die tatsächliche Defect Removal Rate meines Teams?

Verfolgen Sie Defekte, die im Review gefunden wurden, gegen Defekte, die später in Tests oder Produktion gefunden wurden. Das Verhältnis von früh-gefunden zu insgesamt-gefunden ist Ihre Removal Rate. Die meisten Teams verfolgen das nicht, deshalb überschätzen sie die Review-Effektivität. Beginnen Sie damit, zu loggen, wo jeder Defekt gefunden wurde, und berechnen Sie das Verhältnis monatlich.