Code-Review

Kurz: Beim Code-Review prüfen andere Entwicklerinnen und Entwickler Änderungen am Quelltext, bevor sie übernommen werden – auf Fehler, Verständlichkeit, Sicherheit und Stil.

Genauer: Reviews verbessern die Qualität, verteilen Wissen im Team und halten Standards ein. In der Praxis läuft das über Pull Requests (GitHub) oder Merge Requests (GitLab, siehe Git): Die Änderung wird vorgeschlagen, kommentiert, überarbeitet und erst nach Freigabe in den Hauptzweig übernommen. Automatische Prüfungen (Tests, Linter) in der CI/CD-Pipeline ergänzen das.

Im Detail

Worauf achten?

• Korrektheit: Tut der Code, was er soll? Grenzfälle, Fehlerbehandlung (Exceptions)?
• Lesbarkeit: Verständliche Namen, kleine Funktionen (Clean Code)?
• Tests: Gibt es Tests für die neue Logik?
• Sicherheit: Eingaben geprüft, keine Geheimnisse im Code, keine SQL-Injection?
• Leistung und Wartbarkeit: unnötige Komplexität, Duplikate?

Gute Review-Kultur

1. Kleine Änderungen: Pull Requests mit wenigen hundert Zeilen lassen sich gründlich prüfen.
2. Freundlich und konkret: Den Code kritisieren, nicht die Person; Vorschläge statt Befehle.
3. Kommentare unterscheiden: blockierend („muss geändert werden“) und optional („Nit: …“).
4. Schnelle Antwort: Wartende Reviews bremsen das Team.
5. Automatisieren, was geht: Formatierung und Stil erledigt ein Werkzeug, nicht der Mensch.

Eine Variante ist das Pair Programming: zwei Personen arbeiten gleichzeitig an einem Rechner, das Review geschieht live.

Siehe auch: Git, CI/CD-Pipeline, Clean Code, Unit-Test