Im Code Review, auf Deutsch auch Codeprüfung oder Code-Durchsicht, sieht sich jemand anderer eine Änderung an, bevor sie Teil der Software wird. Das Prinzip ist aus anderen Bereichen als Vier-Augen-Prinzip bekannt. In der Praxis läuft das Review meist über einen Pull Request oder Merge Request auf Plattformen wie GitHub, GitLab oder Azure DevOps. Die Änderung wird dort mit dem bisherigen Stand verglichen, kommentiert und erst nach Freigabe übernommen. Das NIST Secure Software Development Framework empfiehlt die Prüfung oder Analyse von menschenlesbarem Code ausdrücklich als Praxis, um Schwachstellen zu finden.
Wie ein Code Review abläuft
- Kleine Änderung vorbereiten: Eine überschaubare Änderung mit einem klaren Zweck lässt sich gründlich prüfen.
- Kontext liefern: Die Beschreibung erklärt, was sich ändert, warum und wie es getestet wurde.
- Automatik zuerst: Die CI/CD-Pipeline prüft Tests, Formatierung und bekannte Schwachstellen, bevor Menschen Zeit investieren.
- Prüfen und kommentieren: Die Reviewerin oder der Reviewer liest die Änderung, stellt Fragen und schlägt Verbesserungen vor.
- Nachbessern: Die Autorin oder der Autor passt die Änderung an oder begründet die Entscheidung.
- Freigeben und übernehmen: Geschützte Branches stellen technisch sicher, dass ohne Freigabe nichts in den Hauptzweig gelangt.
Worauf ein Review achtet
Die öffentlich zugänglichen Engineering Practices von Google nennen unter anderem diese Prüfpunkte:
- Design: Passt die Änderung in das bestehende System?
- Funktion: Tut der Code, was er soll, auch in Randfällen und bei gleichzeitigen Zugriffen?
- Komplexität: Ist es einfacher lösbar? Wird etwas gebaut, das niemand braucht?
- Tests: Sind sie korrekt, sinnvoll und würden sie fehlschlagen, wenn der Code bricht?
- Benennung und Kommentare: Sind Namen klar, erklären Kommentare das Warum?
- Stil, Konsistenz und Dokumentation: Folgt der Code den Vorgaben, ist die Dokumentation aktualisiert?
Für die Sicherheit kommen Fragen hinzu, wie sie der OWASP Code Review Guide beschreibt: Werden Eingaben geprüft und Ausgaben korrekt kodiert? Sind Berechtigungen serverseitig abgesichert? Stehen Zugangsdaten im Code? Werden neue Abhängigkeiten eingeführt, etwa über Composer?
Der richtige Maßstab
Google formuliert einen pragmatischen Maßstab: Reviewer sollten eine Änderung freigeben, sobald sie die Codequalität des Gesamtsystems eindeutig verbessert, auch wenn sie nicht perfekt ist. Kleinigkeiten werden als optionale Hinweise markiert. So bleibt das Review ein Werkzeug für bessere Software und wird nicht zum Engpass.
KI im Code Review
KI-Werkzeuge wie Claude Code können Pull Requests automatisch vorab prüfen und auf mögliche Fehler oder Sicherheitsprobleme hinweisen. Das spart Zeit, ersetzt aber nicht die Verantwortung eines Menschen. Wichtig sind zwei Regeln: Von KI erzeugter Code durchläuft dasselbe Review wie jeder andere Code. Und Firmencode gehört nur in freigegebene Werkzeuge mit geklärter Datenverarbeitung, nicht in private Konten, siehe Schatten-KI.
Typische Fehler
- Sehr große Änderungen, die niemand ernsthaft prüfen kann
- Freigaben ohne echtes Lesen, nur um den Ablauf nicht aufzuhalten
- Lange Diskussionen über Formatierung, die ein automatisches Werkzeug lösen könnte
- Ein persönlicher, abwertender Ton statt sachlicher Hinweise zum Code
- Reviews erst kurz vor dem Liefertermin
Tipps für kleine Teams
Auch in Teams mit zwei oder drei Personen lohnt sich ein Review, zumindest für sicherheitsrelevante Änderungen wie Anmeldung, Berechtigungen, Zahlungen und Datenexporte. Wo niemand intern prüfen kann, hilft ein externes Review in festen Abständen. Dokumentierte Freigaben erleichtern zudem Nachweise gegenüber Auftraggebern.
Abgrenzung
Tests prüfen, ob sich Code wie erwartet verhält. Das Review prüft auch Verständlichkeit, Struktur und Absicht. Statische Analysewerkzeuge finden bestimmte Fehlerklassen automatisch. Ein Penetrationstest greift die laufende Anwendung von außen an. Die Verfahren ergänzen sich und speisen gemeinsam das Schwachstellenmanagement.