Code Review — was ist das, wie funktioniert Code Review und PR-Prüfung

Was ist Code Review

Code Review ist eine systematische Überprüfung des Codes durch Kollegen vor der Integration. Im Git-Kontext bedeutet dies: Ein Entwickler erstellt einen Pull Request mit Änderungen, weist Reviewer zu, und diese studieren den Diff, hinterlassen Kommentare und fällen ein Urteil. Ein Reviewer kann Änderungen anfordern, den PR genehmigen oder einen allgemeinen Kommentar hinterlassen.

Code Review verfolgt fünf Ziele: Verbesserung der Codequalität (Fehlererkennung vor der Produktion), Wissensverbreitung (der Reviewer lernt neue Ansätze, der Autor erhält Feedback), Einhaltung von Standards (Prüfung der Konformität mit Codestil und Architekturentscheidungen), Reduzierung des Bus-Faktors (mehr als ein Entwickler kennt den Code) und Aufbau einer Verantwortungskultur (der Autor schreibt sorgfältiger, weil er weiß, dass der Code überprüft wird).

Das Gegenteil von Code Review ist ein Blind Commit: Ein Entwickler pusht Änderungen in einen gemeinsamen Branch ohne Review. Dieser Ansatz ist nur in Einzelentwickler-Projekten oder für dringende Hotfixes mit anschließendem Review akzeptabel. In der professionellen Teamentwicklung ist Code Review ein obligatorischer Schritt für jede Änderung, einschließlich Dokumentations- und Konfigurationsaktualisierungen.

Was im Code Review prüfen

Code Review sollte systematisch sein, nicht chaotisch. Erfahrene Reviewer prüfen den Code in einer bestimmten Reihenfolge: zuerst Architektur und Logik, dann Tests, dann Sicherheit und Leistung, und erst am Ende — Stil und Benennung. Diese Reihenfolge stellt sicher, dass kritische Probleme bemerkt werden, bevor der Reviewer ermüdet.

Architektur und Logik: Löst der Code die Aufgabe, gibt es übermäßige Abstraktionen, werden die SOLID- und DRY-Prinzipien eingehalten? Komplexer Code, der beim ersten Lesen schwer zu verstehen ist, ist ein Signal, dass Refactoring erforderlich ist. Der Reviewer sollte sicherstellen, dass der Code genau das tut, was die Aufgabe vorgibt, und keine Nebenwirkungen außerhalb seines Verantwortungsbereichs hat.

Tests: Decken die neuen Tests alle Szenarien ab — positive, negative, Grenzfälle. Bestehen die vorhandenen Tests nach den Änderungen? Gibt es flaky Tests, die inkonsistent fehlschlagen? Sicherheit: Fehlen von SQL-Injection, XSS, Datenlecks sensibler Daten durch Logs oder API-Antworten. Leistung: Algorithmeneffizienz, übermäßige Datenbankabfragen, Ressourcenlecks.

• Architektur — Korrektheit der Lösung, SOLID-Konformität, keine Über-Engineering.
• Logik — Behandlung aller Szenarien, einschließlich Fehler und Grenzfälle.
• Tests — Abdeckung neuer Änderungen, keine kaputten vorhandenen Tests.
• Sicherheit — Injection, XSS, CSRF, Datenlecks durch Logs.
• Leistung — Algorithmenkomplexität, N+1-Abfragen, Speicherlecks.

Review-Umfang: Warum 400 Zeilen das Maximum sind

Die PR-Größenbeschränkung ist die wichtigste Metrik für die Effektivität von Code Reviews. Eine Studie von Cisco (2015) und nachfolgende Experimente von SmartBear und Google zeigten, dass bei einem Review-Volumen von mehr als 400 Zeilen die Fähigkeit des Reviewers, Fehler zu finden, drastisch abnimmt. Wenn ein PR 400 Zeilen überschreitet, werden Fehler mit nicht mehr als zufälliger Wahrscheinlichkeit erkannt.

Optimale Größe: 200–400 Zeilen pro PR. Dieser Umfang kann in 30–60 Minuten unter Konzentration überprüft werden. Google empfiehlt nicht mehr als 200 Zeilen pro Review-Runde bei voller Konzentration. Bei größeren Änderungen sollte die Aufgabe in mehrere aufeinanderfolgende PRs zerlegt werden, die jeweils eine logisch abgeschlossene Änderung einführen.

Review-Zeit: innerhalb von 24 Stunden nach PR-Erstellung. Wenn sich das Review über mehrere Tage hinzieht, geht der Aufgabenkontext verloren, und der Autor muss Zeit aufwenden, um den Kontext bei der Beantwortung von Kommentaren wiederherzustellen. Teams mit einer starken Code-Review-Kultur legen SLAs für Reviews fest: beispielsweise 4 Stunden für kritische Änderungen und 24 Stunden für normale.

Wie man gute Review-Kommentare schreibt

Der Ton der Kommentare ist für die Effektivität von Code Reviews von entscheidender Bedeutung. Ein Kommentar wie „Das ist falsch“ löst eine defensive Reaktion aus und liefert dem Autor keine nützlichen Informationen. Eine bessere Formulierung ist eine Frage-Anregung: „Was halten Sie von diesem Ansatz?“, „Dies könnte eine NPE verursachen, wenn user == nil. Vielleicht einen Guard hinzufügen?“. Fragen sind weniger konfrontativ und fördern die Diskussion.

Ein guter Kommentar besteht aus drei Teilen: Was ist falsch, warum ist es ein Problem und wie kann es behoben werden. Beispiel: „Diese Schleife verwendet O(n²) aufgrund eines verschachtelten contains, was bei 10k+ Datensätzen langsam sein könnte. Versuchen Sie, es durch ein Set für O(1)-Suche zu ersetzen.“ Diese Formulierung identifiziert gleichzeitig das Problem, erklärt seine Bedeutung und schlägt eine Lösung vor — der Autor muss nicht raten.

GitHub und GitLab unterstützen Vorschläge — Inline-Code-Änderungsvorschläge. Ein Reviewer kann schreiben: „```suggestion Filter empty strings before processing```“ und der Autor kann die Änderung mit einem Klick übernehmen. Dies beschleunigt kleinere Korrekturen und reduziert die Anzahl der Review-Runden. Bei größeren Änderungen ist es besser, einen allgemeinen Kommentar zu schreiben, anstatt große Blöcke in einen Vorschlag einzubetten.

# Vorlage für guten Code-Review-Kommentar

# SCHLECHT: "This code is wrong"
# GUT: "We may lose data on empty response.
#         If response.data == nil, the guard returns nil,
#         and user sees empty screen without error.
#         Maybe add a fallback error message?"

# GitHub-Vorschlagssyntax:
# ```suggestion
# let result = try? parse(response, fallback: .defaultValue)
# ```

Code-Review-Workflow im Team

Ein effektiver Review-Workflow basiert auf vier Phasen. Erste — der Autor bereitet den PR vor: schreibt einen klaren Titel (z.B. „feat: add password reset screen“), fügt eine Beschreibung der Änderungen, Links zur Aufgabe im Tracker und Testanweisungen hinzu. Zweite — der Autor weist Reviewer per Auto-Assign (basierend auf CODEOWNERS) oder manuell zu.

Die dritte Phase — der Reviewer prüft den Code und hinterlässt Kommentare. Die vierte — der Autor nimmt Korrekturen vor, antwortet auf Kommentare und fordert ein erneutes Review an. Der Zyklus wiederholt sich bis zur Genehmigung. Nach der Genehmigung führt der Autor den Merge durch (oder ein Bot tut es). Automatisierung über Mergify oder GitHub Auto-merge beschleunigt die Endphase.

Ein wichtiges Workflow-Element ist das Stale-PR-Management. Wenn ein PR länger als 3 Tage ohne Review bleibt, wird der Prozess blockiert. Lösungen: Reviewer-Rotation (falls der zugewiesene Reviewer nicht verfügbar ist), Benachrichtigungen über Slack/Teams, Zeitlimit für Reviews (SLA). In manchen Teams wird ein PR ohne Review nach mehr als 7 Tagen automatisch geschlossen, und der Autor erstellt nach der Synchronisierung mit main einen neuen.

• PR-Erstellung — klarer Titel, Beschreibung, Aufgabenlinks, Screenshots bei UI-Änderungen.
• Zuweisung — Auto-Assign via CODEOWNERS oder manuelle Auswahl von 1–2 Reviewern.
• Review — Prüfung in der Reihenfolge: Architektur → Logik → Tests → Sicherheit → Stil.
• Korrekturen — Autor antwortet auf alle Kommentare, behebt blockierende Probleme, fordert erneutes Review an.
• Merge — nach Genehmigung und grünem CI führt der Autor oder Bot den Merge durch.

Häufige Code-Review-Fehler

Der erste Fehler — oberflächliches Review. Der Reviewer scannt schnell den Diff, ohne in die Logik einzutauchen, und klickt auf Approve. Ursachen: großer PR, Deadline, Müdigkeit. Folgen: Fehler gelangen in die Produktion. Lösung: Wenn keine Zeit für ein qualitativ hochwertiges Review ist — schreiben Sie ehrlich „Ich kann heute nicht reviewen, verschieben Sie es auf morgen“ anstelle einer formalen Genehmigung.

Der zweite Fehler — übermäßige Kritik (Nitpicking). Der Reviewer hinterlässt Dutzende Kommentare zum Formatierungsstil, zur Variablenbenennung, zu trivialen Details. Dies demotiviert den Autor und zieht das Review in die Länge. Lösung: StyleGuide und Linters sollten den Stil automatisch prüfen. Der Mensch im Review prüft Logik, Architektur und Sicherheit.

Der dritte Fehler — Review ohne Fragen. Wenn der Reviewer nur Request Changes und Approve postet, aber keine Fragen stellt, verpasst er die Gelegenheit, etwas Neues zu lernen. Der beste Indikator für ein gesundes Code Review ist das Vorhandensein von Diskussionen, in denen beide Seiten etwas Neues lernen. Wenn ein Review ein Monolog eines Teilnehmers ist, ist der Prozess kaputt.

• Oberflächliches Review — Approve ohne tiefgehende Analyse. Lösung: Nicht reviewen, wenn keine Zeit ist.
• Nitpicking — Kritik an Stil, der vom Linter geprüft werden sollte. Lösung: Stilprüfungen automatisieren.
• Persönliche Vorliebe — „Ich hätte es anders geschrieben“. Lösung: Code soll funktionieren, nicht dem Reviewer gefallen.
• Verzögerung — Review länger als 24 Stunden. Lösung: SLA für Reviews, Eskalation bei Verstoß.
• Kontext ignorieren — Code reviewen, ohne die Aufgabe zu verstehen. Lösung: PR-Beschreibung vor dem Diff lesen.