Eine Code-Review durchführen, die den Code verbessert

Ziel

Änderungen genehmigen, die die Codebasis gesünder machen als zuvor, Design- und Korrektheitsprobleme früh erkennen und dies schnell genug tun, dass Reviews die Integration nicht blockieren.

Voraussetzungen

Eine kleine, in sich geschlossene Änderung mit einer Beschreibung, die die Absicht nennt, und Tests, die das neue Verhalten abdecken.

Schritte

1. Zuerst die Beschreibung lesen und entscheiden, ob die Änderung überhaupt sinnvoll ist; ist das Ziel falsch, dies sagen, bevor der Code gelesen wird.
2. Die wichtigsten Teile betrachten: zuerst das Design, dann Korrektheit und Grenzfälle, dann Tests. Googles Leitfaden nennt Design, Funktionalität, Komplexität, Tests, Benennung, Kommentare, Stil, Konsistenz und Dokumentation.
3. Den Rest in absteigender Wichtigkeit kommentieren; optionale Vorschläge entsprechend kennzeichnen ("nit:").
4. Fragen und Begründungen Befehlen vorziehen: "Dieser Zweig ist nicht erreichbar, wenn x leer ist, ist das beabsichtigt?"
5. Genehmigen, wenn die Änderung die allgemeine Codequalität verbessert, auch wenn sie nicht perfekt ist; Änderungen nur bei echten Problemen verlangen, nicht bei persönlichen Vorlieben.
6. Innerhalb eines Arbeitstags antworten; braucht eine vollständige Review länger, Teilrückmeldung senden.

Erwartetes Ergebnis

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

Grenzen und Prüfbasis

Das Vorgehen stammt aus dem zitierten Leitfaden und allgemeiner Praxis; es ersetzt nicht automatisierte Prüfungen auf Stil und statische Fehler, die vor der menschlichen Review laufen sollten. Sehr grosse Änderungen lassen sich mit keinem Vorgehen gut überprüfen und sollten aufgeteilt werden.