Code Review

Was ist Code Review?

Code Review -- auch Peer Review genannt -- ist eine Qualitätssicherungspraxis, bei der mindestens ein anderer Entwickler den geschriebenen Code prüft, bevor er in die Codebasis aufgenommen wird. Dies geschieht typischerweise über Pull Requests (PRs) in Plattformen wie GitHub oder GitLab, wo Änderungen kommentiert, diskutiert und verbessert werden können.

Ein Code Review ist mehr als eine Fehlersuche. Es ist ein Kommunikationswerkzeug, das sicherstellt, dass mehrere Teammitglieder den Code verstehen, dass Architekturentscheidungen gemeinsam getragen werden und dass Wissen nicht in Silos verbleibt. Der Prozess schützt nicht nur vor Bugs, sondern vor allem vor langfristigen Qualitätsproblemen wie inkonsistenter Architektur oder steigender technischer Schuld.

Warum ist das wichtig?

Studien zeigen, dass Code Reviews 60-90% der Defekte finden können, die durch automatisierte Tests nicht abgedeckt werden -- etwa logische Fehler, fehlende Edge Cases, Sicherheitslücken oder Performance-Probleme. Die Kosten für einen in der Review gefundenen Fehler sind um ein Vielfaches geringer als die Kosten für einen Fehler in Produktion.

Noch wichtiger als die Fehlerfindung ist der Wissenstransfer. In einem Team mit fünf Entwicklern kennt bei regelmäßigen Reviews jedes Teammitglied mindestens grob die gesamte Codebasis. Ohne Reviews entstehen "Wissensinseln" -- Bereiche, die nur eine Person versteht. Wenn diese Person das Team verlässt, entsteht ein kritisches Risiko. Code Reviews sind die günstigste Form der Dokumentation, weil sie automatisch im Arbeitsfluss stattfinden.

Für die Teamkultur sind Reviews ebenfalls wertvoll. Sie fördern Diskussionen über Best Practices, etablieren gemeinsame Standards und helfen Junior-Entwicklern, schneller zu lernen. Ein gut geführter Review-Prozess schafft eine Kultur der kollektiven Verantwortung, in der der Code dem Team gehört, nicht einzelnen Personen.

Code Review in der Praxis

Ein effektiver Code-Review-Prozess folgt klaren Regeln:

Scope begrenzen: PRs sollten klein und fokussiert sein -- idealerweise unter 400 Zeilen geänderter Code. Größere PRs werden oberflächlicher reviewt und ziehen mehr Diskussion auf sich. Ein PR pro Feature oder Bugfix ist die Faustregel.

Automatisierung vorschalten: Bevor ein Mensch den Code sieht, sollten Linter, Formatter, Typ-Checker und automatisierte Tests in der CI/CD-Pipeline durchlaufen sein. Code Review ist zu wertvoll, um für Stilfragen oder fehlende Semikolons verschwendet zu werden. Automatisierte Tools übernehmen die mechanische Prüfung, Menschen konzentrieren sich auf Logik, Architektur und Lesbarkeit.

Review-Checkliste: Gute Reviewer prüfen systematisch: Ist die Logik korrekt? Werden Edge Cases behandelt? Ist der Code testbar und getestet? Gibt es Sicherheitsrisiken? Ist die Performance akzeptabel? Ist der Code für andere Entwickler verständlich?

Konstruktives Feedback: Reviews beschreiben Probleme und schlagen Alternativen vor, statt nur zu kritisieren. "Diese Funktion hat eine zyklomatische Komplexität von 12 -- könnten wir sie in kleinere Funktionen aufteilen?" ist hilfreicher als "Zu komplex". Feedback bezieht sich auf den Code, nie auf die Person.

Beispiel: Ein Team mit vier Entwicklern nutzt GitHub PRs mit einer Branch-Protection-Rule: Mindestens ein approving Review ist erforderlich, bevor ein Merge möglich ist. Die CI/CD-Pipeline prüft automatisch Linting, TypeScript-Kompilierung und Testabdeckung. Der Reviewer fokussiert sich auf Geschäftslogik, Architekturkonformität und potenzielle Seiteneffekte. Die durchschnittliche Review-Zeit beträgt zwei Stunden -- kurz genug, um den Arbeitsfluss nicht zu blockieren, gründlich genug, um Qualität zu sichern.

Ein häufiger Fehler ist das Gatekeeping -- wenn Reviews zum Machtinstrument werden und PRs tagelang unbearbeitet liegen. Eine gesunde Review-Kultur priorisiert Reviews als Teamverantwortung und setzt SLAs von maximal einem Arbeitstag für die erste Rückmeldung.

Verwandte Konzepte

• CI/CD Pipeline -- Automatisierte Qualitätsprüfung vor und nach dem Review
• Technical Debt -- Reviews verhindern, dass technische Schulden unkontrolliert wachsen
• Agile vs Kanban -- Reviews als fester Bestandteil agiler Workflows
• Unser Team -- Wie unser Review-Prozess Qualität sichert
• Technical Debt abbauen -- Strategien für nachhaltige Codequalität