Code Review: Best Practices für Autoren und Reviewer

Was ist ein Code Review?

Ein Code Review (auch Code-Review oder Codeprüfung) ist die Prüfung einer Codeänderung durch mindestens eine weitere Person, bevor die Änderung gemergt wird. Die deutsche Wikipedia ordnet es als eine Form des Reviews im Softwaretest ein, bei dem Arbeitsergebnisse der Softwareentwicklung manuell geprüft werden. In der Praxis passiert das heute fast immer im Pull Request auf GitHub oder im Merge Request auf GitLab: Die Autorin stellt die Änderung zur Diskussion, Reviewer kommentieren einzelne Zeilen, und erst nach einer Genehmigung landet der Code im Hauptzweig.

Ein Code Review hat vier Ziele:

• Fehler früh finden, solange die Autorin den Code noch im Kopf hat und eine Korrektur wenig kostet.
• Das Design prüfen, also ob die Änderung an die richtige Stelle gehört und das System langfristig wartbar bleibt.
• Konsistenz sichern: gleiche Konventionen, gleiche Muster, gleiche Fehlerbehandlung im ganzen Codebestand.
• Wissen verteilen, damit mehr als eine Person jeden Teil des Systems versteht und niemand zum Engpass wird.

Googles Engineering Practices fassen den Maßstab eines Code Reviews in einem Satz zusammen: Eine Änderung sollte genehmigt werden, sobald sie die Gesamtqualität des Codes eindeutig verbessert, auch wenn sie nicht perfekt ist. Perfekten Code gibt es nicht, nur besseren. Jeder Kommentar lässt sich daran messen, ob er den Code besser oder nur anders macht.

Ablauf eines Code Reviews im Pull Request

Der Ablauf folgt Googles Leitfaden zum Navigieren einer Änderung, übertragen auf die deutsche Oberfläche von GitHub:

1. Beschreibung lesen: Lies die Beschreibung des Pull Requests und das verknüpfte Ticket und entscheide, ob die Änderung in dieser Form überhaupt sinnvoll ist.
2. Die zentrale Datei zuerst prüfen: Öffne im Tab „Dateien geändert“ die Datei mit der wichtigsten Logik und prüfe das Design, bevor du ins Detail gehst.
3. Die übrigen Dateien der Reihe nach lesen: Geh die restlichen Dateien in der angezeigten Reihenfolge durch, lies die Tests mit und hake jede Datei als „Gesehen“ ab.
4. Kommentare mit Begründung und Gewichtung schreiben: Starte mit „Review starten“, kommentiere einzelne Zeilen, begründe jeden Wunsch und markiere optionale Punkte mit Nit, Optional oder FYI.
5. Review absenden: Sende das Review als Kommentar, Genehmigen oder Änderungen anfordern ab und schreib in die Zusammenfassung, welche Punkte den Merge blockieren.

Ein Detail spart in der zweiten Runde Zeit: Ändert sich eine Datei, nachdem du sie als „Gesehen“ markiert hast, entfernt GitHub die Markierung wieder. Du siehst also sofort, was seit deinem letzten Durchgang neu ist. Kommentare, die du mit „Review starten“ sammelst, bleiben ausstehend, bis du sie mit „Review senden“ gemeinsam abschickst.

Code Review Best Practices für Autoren

1. Pull Requests klein halten. Googles Leitfaden nennt 100 geänderte Zeilen meist angemessen und 1.000 meist zu groß; 200 Zeilen über 50 Dateien verteilt sind ebenfalls zu viel. Kleine Änderungen werden schneller und gründlicher geprüft, bringen weniger Bugs mit und lassen sich leichter zurückrollen.
2. Die Absicht beschreiben, nicht nur den Diff. Welches Problem löst die Änderung, warum dieser Ansatz, was wurde bewusst weggelassen? Verlinke das Ticket und nenne die Datei mit der zentralen Logik.
3. Refactoring und Verhaltensänderung trennen. Eine Umbenennung über 40 Dateien versteckt die drei Zeilen, die das Verhalten ändern. Mechanische Änderungen gehören in einen eigenen Pull Request.
4. Den eigenen Diff zuerst lesen. Debug-Ausgaben, auskommentierter Code und fehlende Tests fallen dir im Review-Tool selbst auf, bevor jemand anderes Zeit darauf verwendet.
5. CI und automatisches Review abwarten. Formatierung, Linter-Fehler und rote Tests sollten keine Aufmerksamkeit eines Menschen kosten.
6. Auf jeden Kommentar antworten. Umsetzen oder begründet widersprechen. Eine im Thread geklärte Meinungsverschiedenheit ist besser als ein stiller Push, den der Reviewer erneut vergleichen muss.

Code Review Best Practices für Reviewer

7. Innerhalb eines Arbeitstags reagieren. Laut Googles Leitfaden ist ein Arbeitstag die maximale Zeit bis zur ersten Antwort auf eine Review-Anfrage. Eine schnelle erste Reaktion zählt mehr als ein schnelles vollständiges Review.
8. In der richtigen Reihenfolge lesen. Erst die Beschreibung, dann die Datei mit der wichtigsten Logik. Ein Designproblem dort kann den Rest des Reviews überflüssig machen; melde es sofort.
9. Sitzungen kurz halten. SmartBear berichtet aus einer Studie mit einem Entwicklungsteam von Cisco Systems, dass 200 bis 400 Zeilen in 60 bis 90 Minuten 70 bis 90 % der Fehler aufdecken, dass die Trefferquote bei mehr als 500 Zeilen pro Stunde deutlich sinkt und die Konzentration nach etwa 60 Minuten nachlässt.
10. Mit Nits genehmigen. Google empfiehlt, auch mit offenen Kommentaren zu genehmigen, wenn sie klein sind oder du darauf vertraust, dass die Autorin sie umsetzt. Das spart eine komplette Runde, besonders über Zeitzonen hinweg.
11. Die Review-Entscheidung bewusst wählen. „Kommentar“ für Feedback ohne Entscheidung, „Genehmigen“ für eine Freigabe, „Änderungen anfordern“ nur für Punkte, die vor dem Merge wirklich behoben sein müssen.

Code-Review-Kommentare, die ankommen

Kommentiere den Code, nicht die Person. Googles Leitfaden nennt dafür ein Beispiel: „Warum hast du hier Threads verwendet, obwohl Nebenläufigkeit offensichtlich nichts bringt?“ klingt wie ein Vorwurf. „Das Nebenläufigkeitsmodell macht den Code komplexer, ohne dass ich einen Performance-Gewinn sehe“ beschreibt den Code. Begründe jeden Wunsch und schlage, wo möglich, eine Richtung vor.

Markiere außerdem, wie wichtig ein Kommentar ist:

• Nit: Kleinigkeit, die die Autorin ignorieren darf.
• Optional: Eine Idee, die sich lohnen könnte, aber keine Bedingung ist.
• FYI: Information für später, in diesem Pull Request ist nichts zu tun.

Kommentare ohne Kennzeichnung lesen sich wie Pflicht. Wenn ein Reviewer Fehler, Design- Einwände und Geschmacksfragen gleich formuliert, kann die Autorin nicht erkennen, was den Merge blockiert. Präfixe wie Nit, Optional und FYI aus Googles Engineering Practices trennen beides und erlauben eine Genehmigung, während Kleinigkeiten noch offen sind.

Code Review Checkliste

Diese Fragen decken die Bereiche ab, in denen Reviews die meisten Probleme finden:

• Design: Gehört die Änderung an diese Stelle? Passt sie zur bestehenden Architektur, oder ist sie komplizierter als nötig?
• Korrektheit: Tut der Code, was die Beschreibung verspricht? Was passiert bei leeren Eingaben, Grenzwerten, Fehlern und parallelen Zugriffen?
• Tests: Prüfen die neuen Tests das beschriebene Verhalten? Wurden bestehende Tests gelockert, damit sie grün werden?
• Sicherheit und Daten: Werden Eingaben validiert, Rechte geprüft und keine Secrets oder personenbezogenen Daten geloggt?
• Performance: Gibt es Abfragen in Schleifen, unnötige Netzwerkaufrufe oder Daten, die ohne Grenze wachsen?
• Lesbarkeit: Sind Namen klar, und erklären Kommentare das Warum statt des Was?

Alles, was ein Tool prüfen kann, gehört in die CI statt auf die Checkliste: Formatter und Linter klären Einrückung, Importreihenfolge und Namenskonventionen bei jedem Lauf. Regeln, die Reviewer immer wieder in Kommentaren wiederholen, schreibst du besser auf: Coding-Konventionen in AGENTS.md, Hinweise nur fürs Review in REVIEW.md, und Anforderungen, deren Verletzung teuer wäre, als Prüfung, die bei jedem passenden Pull Request läuft.

KI-gestützte Code Reviews

Seit Coding-Agents Pull Requests öffnen, wächst die Menge an Code, die ein Team prüfen muss. Diese Pull Requests brauchen dasselbe Review, oft sogar mehr. In unserem Benchmark zum Review von Agent-Code (englisch) haben acht Coding-Agents dieselben zwei Features in Umami, einer Open-Source-Analytics-App, gebaut, und alle 16 Pull Requests enthielten Probleme.

Von den 119 Problemen, die HeyDeer in diesen 16 Pull Requests von Coding-Agents fand und jeweils am Code verifizierte, waren 3 schwerwiegend, 54 mittel und 62 gering; keines war kritisch. Meist ging es um begrenzte funktionale, Performance- oder Wartungsschäden, also genau die Art von Fehlern, die sich unbemerkt anhäufen.

Ein KI-Reviewer bringt am meisten, wenn er zuerst prüft. Das Setup, das HeyDeer für Teams mit menschlichen Prüfern empfiehlt: HeyDeer reviewt bei jedem Push, der Check schlägt fehl, solange Befunde offen sind, und die Branch-Regeln verlangen diesen Check. Menschen beginnen erst danach mit dem Lesen und konzentrieren sich auf Design, Produktverhalten und die Fragen, die HeyDeer unter „Klärung erforderlich“ auflistet.

• Formatierung und Lint: CI, bei jedem Lauf.
• Fehlerbehandlung, Grenzwerte, Nebenläufigkeit, kaputte Aufrufer: KI-Reviewer, bei jedem Push.
• Teamregeln, deren Verletzung teuer wäre: Repository-Prüfungen, bei jedem passenden Pull Request.
• Design, Produktverhalten, Sinn der Änderung: Menschen, nachdem das automatische Review bestanden ist.

Bei Code von Agents lohnt ein genauerer Blick auf die Aufgabe selbst: Lies das Ticket oder den Prompt, mit dem der Agent gearbeitet hat, und prüfe, ob die Änderung genau das tut. Ein Modell, das den Code geschrieben hat, übernimmt gern die eigene Argumentation und übersieht die eigenen Fehler; ein vom Autor getrennter Reviewer findet mehr. Prüfe außerdem jeden Push, nicht nur den ersten, denn wiederholte Überarbeitungen können stillschweigend kaputt machen, was vorher funktioniert hat.

Wenn ein automatischer Reviewer Kommentare schreibt, auf die niemand reagiert, liegt das meist an der Konfiguration: „Feedback-Umfang“ auf „Kompakt“ stellen, generierte Dateien ausnehmen, Bot-Pull-Requests filtern. Der Leitfaden Rauschen reduzieren listet jede Maßnahme. HeyDeer läuft auf GitHub, hat einen dauerhaft kostenlosen Plan, und die Preise der bezahlten Pläne stehen offen auf der Website. Einen direkten Vergleich mit einem verbreiteten Tool zeigt HeyDeer vs. CodeRabbit.

Quellen

1. Wikipedia: Review (Softwaretest)
2. GitLab: Was ist eine Code Review?
3. GitHub Docs: Vorgeschlagene Änderungen in einem Pull Request überprüfen
4. Google Engineering Practices: The standard of code review
5. Google Engineering Practices: Speed of code reviews
6. Google Engineering Practices: Small CLs
7. Google Engineering Practices: Navigating a CL in review
8. Google Engineering Practices: How to write code review comments
9. SmartBear: Best practices for peer code review