Clean Code #8: Code Reviews — Das Vier-Augen-Prinzip

Code Reviews sind keine Kritik am Entwickler — sie sind eine Investition in die Codequalität des gesamten Teams. Richtig gemacht, verbessern sie nicht nur den Code, sondern auch die Fähigkeiten jedes Teammitglieds.

Warum Code Reviews?

Studien zeigen, dass Code Reviews 60-90% aller Bugs finden können — mehr als jede andere Qualitätsmaßnahme. Aber der eigentliche Wert geht weit darüber hinaus:

• •Wissensverteilung: Kein Code-Abschnitt ist nur einer Person bekannt
• •Konsistenz: Das Team entwickelt einen gemeinsamen Stil
• •Lerneffekt: Junior-Entwickler lernen, Senior-Entwickler hinterfragen Annahmen
• •Sicherheit: Vier Augen sehen mehr als zwei — besonders bei Security-relevant Code

Was ein Reviewer prüfen sollte

1. Verständlichkeit

Die wichtigste Frage: Verstehe ich, was dieser Code tut? Wenn nicht, ist der Code zu komplex — nicht der Reviewer zu unerfahren.

2. Korrektheit

Tut der Code das, was er soll? Werden Edge-Cases behandelt? Was passiert bei leeren Listen, null-Werten, negativen Zahlen?

3. Design

Passt die Architektur? Werden die SOLID-Prinzipien eingehalten? Gibt es unnötige Komplexität?

4. Tests

Sind Tests vorhanden? Testen sie das richtige Verhalten? Werden Edge-Cases abgedeckt?

5. Performance (bei Bedarf)

Gibt es offensichtliche Performance-Probleme? N+1 Queries? Unnötige Schleifen? Aber: Micro-Optimierung ist selten der richtige Fokus.

Wie man gutes Feedback gibt

// ❌ Destruktiv
"Das ist schlecht."
"Warum hast du das so gemacht?"
"Das hätte ich anders gelöst."

// ✅ Konstruktiv
"Könnten wir hier ein Strategy Pattern verwenden?
  Das würde die switch-Anweisung eliminieren."

"Nit: Diesen Variablennamen finde ich etwas kurz.
  Was hältst du von 'customerOrderHistory'?"

"Frage: Ist es beabsichtigt, dass null hier
  nicht behandelt wird? Könnte das zu Problemen führen?"

Regeln für effektive Reviews

• •Klein halten: Reviews unter 400 Zeilen. Größere PRs in mehrere aufteilen
• •Zeitnah: Innerhalb von 24 Stunden reviewen
• •Automatisieren: Formatierung, Linting, Typen — das macht die Maschine
• •Kontext geben: Der PR-Autor sollte erklären, warum die Änderung nötig ist
• •Respektvoll: Kritisiere den Code, nicht die Person

Die Review-Checkliste

Eine pragmatische Checkliste für jeden Review:

• ☐ Verstehe ich den Zweck der Änderung?
• ☐ Sind die Namen sprechend?
• ☐ Sind die Funktionen klein und fokussiert?
• ☐ Gibt es Duplikation?
• ☐ Werden Fehler sinnvoll behandelt?
• ☐ Sind Tests vorhanden und sinnvoll?
• ☐ Gibt es Security-Bedenken?

Fazit

Code Reviews sind kein Overhead — sie sind die effektivste Methode, um Code-Qualität, Team-Wissen und Software-Sicherheit gleichzeitig zu verbessern. Machen Sie sie zur Gewohnheit, nicht zur Pflicht.

Nächster Artikel: Clean Code #9: Refactoring — Kontinuierliche Verbesserung