Code-Review: Was wird dabei geprüft?

Die Prüfliste, in dieser Reihenfolge

• Tut die Änderung, was sie soll? Der Abgleich mit der Aufgabe, nicht mit dem eigenen Geschmack.
• Was passiert im Fehlerfall? Fehlende Daten, doppelte Eingaben, nicht erreichbare Systeme.
• Sind Rechte und Zuständigkeiten geprüft — und zwar auf dem Server, nicht nur in der Oberfläche?
• Gibt es Tests für die Fälle, die weh tun, und fallen sie ohne die Änderung durch?
• Passt die Änderung zum Aufbau der Anwendung, oder schafft sie eine zweite Art, dasselbe zu tun?
• Ist sie lesbar genug, dass die nächste Änderung daran keine Archäologie wird?

Die Reihenfolge ist nicht beliebig. Ein Review, das bei Punkt sechs beginnt und die Punkte eins bis drei nie erreicht, hat die teure Zeit auf die billigen Fragen verwendet.

Jeder Befund braucht ein Fehlerszenario

Das ist die Regel, die ein Review nützlich hält: Wer etwas beanstandet, nennt eine konkrete Eingabe und das konkrete falsche Verhalten, das daraus folgt — oder eine benannte Regel, gegen die verstoßen wird.

„Das würde ich anders machen" ist kein Befund. „Bei einer Menge von 0 rechnet diese Zeile durch Null, und die Oberfläche zeigt dann eine leere Seite statt einer Meldung" ist einer. Der Unterschied entscheidet, ob ein Review Fehler findet oder Diskussionen erzeugt.

Daraus folgt auch: Ein Review ohne Befunde ist das erwartete Normalergebnis, kein Zeichen von Nachlässigkeit. Wer in jedem Review etwas finden muss, findet irgendwann Geschmacksfragen.

Was ein Review nicht leisten kann

• Es ersetzt keine Tests. Lesen findet andere Fehler als Ausführen.
• Es ersetzt keinen Test im Browser. Dass eine Funktion richtig aussieht, heißt nicht, dass die Seite sie erreicht.
• Es findet keine Fehler in Code, den niemand liest — eine Änderung über tausend Zeilen wird nicht wirklich geprüft.

Deshalb gilt bei uns: eine Änderung pro Thema, prüfbar in einem Durchgang. Wer drei Themen in eine Änderung packt, bekommt ein Review über das erste.