Code-Review: eine Checkliste für Reviewer

Ziel

Änderungen freigeben, die den Code insgesamt verbessern, Design- und Korrektheitsprobleme früh finden und so schnell antworten, dass Reviews die Integration nicht blockieren.

Voraussetzungen

Eine kleine, in sich geschlossene Änderung mit einer Beschreibung, die den Zweck nennt, und mit Tests für das neue Verhalten.

Schritte

1. Beschreibung lesen und entscheiden, ob die Änderung überhaupt sinnvoll ist; falls das Ziel falsch ist, das zuerst sagen.
2. Zuerst das Wichtige prüfen: Design, dann Korrektheit und Randfälle, dann Tests. Die zitierte Anleitung nennt Design, Funktionalität, Komplexität, Tests, Benennung, Kommentare, Stil, Konsistenz und Dokumentation.
3. Weitere Punkte in absteigender Wichtigkeit anmerken; optionale Hinweise als solche kennzeichnen («nit:»).
4. Fragen und Begründungen statt Befehle: «Dieser Zweig ist unerreichbar, wenn x leer ist – beabsichtigt?»
5. Freigeben, sobald die Änderung den Code insgesamt verbessert, auch wenn sie nicht perfekt ist; Änderungen nur bei echten Problemen verlangen, nicht bei Geschmacksfragen.
6. Innerhalb eines Arbeitstags antworten; dauert ein vollständiges Review länger, Zwischenstand senden.

Erwartetes Ergebnis

Reviews finden Design- und Korrektheitsprobleme statt nur Formatierung; Autorinnen und Autoren erhalten umsetzbare Kommentare; Änderungen warten Stunden, nicht Tage.

Grenzen und Prüfbasis

Die Liste ersetzt keine automatischen Prüfungen für Stil und statische Fehler, die vor dem menschlichen Review laufen sollten. Sehr grosse Änderungen lassen sich mit keiner Liste gut prüfen und sollten aufgeteilt werden.