Die folgende Checkliste ist als kompakter Teamstandard gedacht. Sie hilft dabei, Reviews nachvollziehbar zu machen, ohne aus jeder Änderung eine Grundsatzdiskussion zu machen.
1. Ziel und Umfang verstehen
Ist klar, welches Problem die Änderung löst? Passt der Code zum Ticket und bleibt der Umfang auf die eigentliche Aufgabe begrenzt?
2. Funktion und Randfälle prüfen
Erfüllt die Änderung die erwartete Funktion? Sind typische Fehlerfälle, leere Werte, Grenzwerte und ungültige Eingaben berücksichtigt?
3. Lesbarkeit und Benennung
Sind Namen, Struktur und Kontrollfluss verständlich? Muss ein Reviewer unnötig viel Kontext rekonstruieren, sollte der Code oder die Beschreibung klarer werden.
4. Tests passend zur Änderung
Decken automatisierte Tests die neue oder geänderte Logik sinnvoll ab? Wichtig ist nicht maximale Testmenge, sondern Schutz der relevanten Verhaltensweisen.
5. Architektur und Abhängigkeiten
Passt die Änderung in bestehende Verantwortlichkeiten und Schichten? Werden unnötige Kopplungen, Sonderwege oder neue Abhängigkeiten vermieden?
6. Sicherheit und Daten
Werden Eingaben validiert, Berechtigungen respektiert und sensible Daten angemessen behandelt? Neue externe Abhängigkeiten sollten bewusst geprüft werden.
7. Betrieb und Wartbarkeit
Sind Logging, Fehlerbehandlung, Konfiguration oder Migrationen nötig? Kann das Team die Änderung später nachvollziehen und betreiben?
8. Review fokussiert abschließen
Blockierende Punkte klar von optionalen Verbesserungsvorschlägen trennen. Kleine Stilfragen sollten ein Review nicht unnötig stoppen, wenn sie bereits durch Standards oder Formatter geregelt sind.