Code Reviews richtig durchführen
Ein Code Review, das nur nach Fehlern sucht, nutzt den kleineren Teil seines Potenzials – Fehler findet statische Analyse billiger und zuverlässiger. Der eigentliche Wert liegt darin, dass Wissen im Team zirkuliert, Entscheidungen begründet werden und niemand allein für einen Bereich verantwortlich bleibt. Dieser Artikel zeigt, wie Reviews praktisch ablaufen, worauf zu schauen ist, wie Feedback ankommt – und warum das Thema 2026 dringlicher geworden ist als je zuvor.
Was ein Review eigentlich leistet
Vier Wirkungen, in der Reihenfolge ihres tatsächlichen Werts:
Die nützlichste Haltung: Ein Review beantwortet nicht die Frage „Ist dieser Code gut?“, sondern „Kann ich diese Änderung in einem halben Jahr verstehen und ändern, ohne den Autor fragen zu müssen?“ Diese Umformulierung verhindert die meisten unergiebigen Diskussionen – und macht Geschmacksfragen von Substanzfragen unterscheidbar.
Der Pull-Request-Workflow
Der Ablauf ist bei GitHub, GitLab und Bitbucket praktisch identisch.
Die wichtigste Zahl im ganzen Thema: Reviewqualität hängt fast linear an der Änderungsgröße. Bei unter 200 geänderten Zeilen lesen Reviewer tatsächlich; bei über 500 beginnt das Durchblättern; bei über 1.000 bekommen Sie ein „sieht gut aus“ ohne Erkenntniswert. Wenn Ihre Reviews nichts finden, liegt das in den meisten Fällen nicht an den Reviewern, sondern an der Größe der Pakete.
Die Review-Checkliste
Reviewer arbeiten besser mit einer Reihenfolge als mit einer Liste. Von oben nach unten, und bei einem Problem auf einer oberen Ebene gar nicht erst nach unten gehen.
1. Richtigkeit und Zweck
Löst die Änderung das beschriebene Problem? Sind die Randfälle bedacht – leere Eingabe, Null-Werte, gleichzeitige Zugriffe, Fehler des aufgerufenen Dienstes? Wird im Fehlerfall sinnvoll reagiert oder nur geschwiegen?
2. Sicherheit
Hier lohnt die größte Aufmerksamkeit, weil Fehler teuer sind und automatische Prüfung nur einen Teil erfasst. Die Fehlerklasse, die hier gesucht wird, ist dieselbe, auf die ein Penetrationstest zielt – nur deutlich billiger gefunden:
Zu den Grundlagen der Zugriffskontrolle siehe OAuth 2.0 und JWT.
3. Tests
Gibt es Tests für das neue Verhalten? Prüfen sie das Ergebnis oder nur, dass nichts abstürzt? Decken sie mindestens einen Fehlerfall ab? Ein Test ohne Prüfung ist schlimmer als kein Test, weil er Sicherheit vortäuscht. Mehr dazu im Unit Testing Guide.
4. Architektur und Passung
Liegt die Änderung an der richtigen Stelle? Folgt sie dem Muster, das das Projekt sonst verwendet, oder führt sie ein zweites ein? Entsteht eine Abhängigkeit, die die Schichtung verletzt? Wird etwas nachgebaut, das es schon gibt?
5. Lesbarkeit
Sagen die Namen, was gemeint ist? Ist die Funktion in einem Durchgang verständlich? Erklären Kommentare das Warum – oder wiederholen sie das Was? Siehe Clean Code.
6. Betrieb
Lässt sich erkennen, wenn diese Änderung in Produktion Probleme macht? Gibt es Protokollierung an den relevanten Stellen? Ist eine Datenbankänderung rückwärtskompatibel, damit eine Rücknahme möglich bleibt?
Was ausdrücklich nicht ins Review gehört: Formatierung, Anführungszeichen, Importreihenfolge, Zeilenlänge. Das erledigt ein automatischer Formatierer. Jede Minute, die ein Mensch darauf verwendet, ist verschwendet – und jede Diskussion darüber kostet Reviewbereitschaft, die später bei den wichtigen Punkten fehlt.
Feedback, das ankommt
Reviews sind der Ort, an dem Teamkultur sichtbar wird. Vier Regeln machen den Unterschied zwischen einem Werkzeug und einem Konfliktherd.
Über den Code sprechen, nicht über die Person
„Hier fehlt die Prüfung auf den leeren Fall“ statt „Du hast vergessen“. Formal eine Kleinigkeit, in der Wirkung erheblich – besonders in schriftlicher Form, wo Tonfall fehlt.
Zwischen Muss, Sollte und Könnte unterscheiden
Die wirksamste Einzelmaßnahme überhaupt. Markieren Sie jede Anmerkung:
| Marker | Bedeutung | Blockiert |
|---|---|---|
| muss | Fehler, Sicherheitsproblem, fehlender Test | ja |
| sollte | sinnvolle Verbesserung, nicht zwingend jetzt | nein, aber Antwort nötig |
| könnte | Idee, Geschmack, Hinweis für später | nein |
| frage | ich verstehe es nicht, bitte erklären | nein |
Ohne diese Einteilung wirkt jede Anmerkung wie eine Forderung. Zwanzig unmarkierte Kommentare lesen sich als Generalkritik, auch wenn achtzehn davon Ideen waren.
Begründen statt anweisen
„Mach das anders“ erzeugt Widerstand. „Das bricht, wenn die Liste leer ist – hier ein Beispiel“ erzeugt Einsicht. Eine Anmerkung ohne Begründung ist eine Geschmacksäußerung mit Autoritätsanspruch.
Loben, wo es etwas zu loben gibt
Zwei Sätze zu einer eleganten Lösung kosten nichts und ändern die Stimmung eines Reviews grundlegend. Reviews, in denen nur Mängel benannt werden, erzeugen Teams, die Reviews meiden.
Für Autoren von Änderungen: Ein Review ist keine Bewertung Ihrer Arbeit, sondern ein zweites Paar Augen. Wer eine Anmerkung nicht umsetzen will, antwortet mit einer Begründung statt mit Zustimmung ohne Änderung. Und bei mehr als zwei Antwortrunden zum gleichen Punkt: Gespräch statt Kommentarkette. Ein Thema, das schriftlich nicht in zwei Runden geklärt ist, wird es auch in sechs nicht.
Automatisierung: was Maschinen besser können
Jede Prüfung, die eine Maschine erledigen kann, sollte kein Mensch erledigen. Die sinnvolle Aufteilung:
| Prüfung | Werkzeug | Wann |
|---|---|---|
| Formatierung | automatischer Formatierer | beim Speichern, nicht im Review |
| Stil, offensichtliche Fehler | Linter | vor dem Commit und in der Pipeline |
| Typfehler, toter Code | statische Analyse | in der Pipeline |
| Testabdeckung des neuen Codes | Abdeckungsbericht | als Pipeline-Schwelle |
| Bekannte Lücken in Abhängigkeiten | Abhängigkeitsprüfung | täglich und bei jedem PR |
| Geheimnisse im Code | Secret Scanning | vor dem Commit |
| Zuständigkeit für einen Bereich | Code Owners | automatische Reviewer-Zuweisung |
Zwei Einrichtungsempfehlungen aus der Praxis: Pipeline-Schwellen auf neuen Code anwenden, nicht auf den Bestand. Ein Team mit 40 Prozent Abdeckung kann 80 Prozent für geänderte Zeilen verlangen, ohne vorher monatelang nachzurüsten. Und Code Owners eintragen: Damit landen Änderungen automatisch bei den Leuten, die den Bereich kennen, statt bei denen, die zuerst Zeit haben. Wie das in die Pipeline eingebettet wird, zeigt der CI/CD-Guide.
KI-Review: nützlich, aber nicht als Ersatz
Werkzeuge, die Pull Requests automatisch kommentieren, sind inzwischen ausgereift genug für den praktischen Einsatz. Sie sind gut bei Mustern – fehlende Fehlerbehandlung, offensichtliche Nebenwirkungen, vergessene Null-Prüfungen – und bei dem, was Menschen ungern tun: dem fünfzigsten Review am Tag. Sie sind schwach bei allem, was Projektkontext braucht: Ist das die richtige Stelle? Passt das zur Fachlogik? Gibt es das schon?
Der sinnvolle Einsatz ist deshalb als Vorfilter, nicht als Freigabeinstanz: Die Maschine kommentiert zuerst, der Autor arbeitet das Offensichtliche ab, der menschliche Reviewer bekommt eine bereits bereinigte Änderung. Wichtig ist, dass maschinelle Anmerkungen klar als solche erkennbar sind und nicht blockieren – sonst verlagert sich die Diskussion von Code auf Werkzeugverhalten.
Der neue Engpass: warum das Thema 2026 dringlicher ist
Dieser Abschnitt ist der Grund, warum Code Reviews gerade wieder diskutiert werden. Mit KI-Unterstützung schreiben Teams mehr Code in kürzerer Zeit. Die Reviewkapazität ist aber nicht gewachsen – und damit verschiebt sich der Engpass.
Die Zahlen sind deutlich. Telemetriedaten über mehr als 10.000 Entwickler in rund 1.250 Teams zeigen bei gleichzeitig gestiegener Aufgabenzahl eine um ein Mehrfaches gestiegene Medianzeit im Review, eine Zunahme der Pull-Request-Größe um rund die Hälfte und deutlich mehr Störungen pro Pull Request. Eine Längsschnittstudie lokalisiert den Zusatzaufwand präzise: Nicht die Zeit des Schreibens unterscheidet sich zwischen maschinell und menschlich erzeugtem Code, sondern die Zeit zwischen erstem Review und Zusammenführung.
Der DORA-Report zum wirtschaftlichen Nutzen von KI-Unterstützung kommt zum passenden Befund: KI wirkt als Verstärker des bestehenden Systems. Teams mit guter Testabdeckung, kleinen Änderungspaketen und funktionierendem Lieferfluss gewinnen Kapazität. Teams mit langsamen Reviews und fragilen Tests verstärken ihre bestehenden Probleme.
Was daraus folgt, ist unbequem und einfach: Mehr Code zu erzeugen hilft nichts, wenn er im Review liegen bleibt. Die praktischen Konsequenzen – und die DORA-Empfehlungen decken sich damit – sind: Änderungspakete klein halten, auch und besonders bei maschinell erzeugtem Code; eine Obergrenze für Pull-Request-Größe vereinbaren; Reviewzeit als festen Teil der Kapazitätsplanung behandeln statt als Nebentätigkeit; und Reviewdauer messen, nicht Reviewanzahl.
Kennzahlen, die den Engpass sichtbar machen
Vier Zahlen genügen, und alle vier lassen sich aus den Daten Ihrer Plattform gewinnen:
Was Sie nicht messen sollten: Anzahl der Kommentare pro Reviewer, Anzahl gefundener Fehler, Reviewgeschwindigkeit pro Person. Alle drei sind steuerbar und erzeugen genau das falsche Verhalten.
Fazit
Gute Reviews sind weniger Fehlersuche als Wissensverteilung und Qualitätssicherung an einer Stelle, an der Korrekturen noch billig sind. Was sie in der Praxis gelingen lässt, sind drei unspektakuläre Dinge: kleine Änderungspakete, eine klare Reihenfolge der Prüfkriterien von Richtigkeit über Sicherheit bis Lesbarkeit, und Anmerkungen, die zwischen Muss und Idee unterscheiden. Alles Formale übernimmt Automatik – jede Minute, die ein Mensch mit Formatierung verbringt, fehlt bei der Logik. Und der Punkt, der 2026 am meisten zählt: Wer mit KI-Unterstützung mehr Code produziert, ohne die Reviewkapazität mitzudenken, verlagert den Engpass nur – messbar, und in den vorliegenden Daten deutlich.