Code Reviews gehören zur gängigen Praxis in Entwicklungsteams. Ziel eines Code Reviews ist es, mögliche Fehler oder Vereinfachungen zu identifizieren, um langfristig die Codequalität zu steigern.
Die grundsätzliche Code Review Regel ist schnell aufgestellt:
Bevor ein Ticket den Status "Fertig" erlangen darf,
sieht die Definition of Done vor,
dass der Software-Code durch ein anderes Teammitglied geprüft wird.
Nicht immer schreibt die Definition of Done ein grundsätzliches Code Review vor. Manchmal sind es auch nur gezielt ausgewählte Tickets, die ein Code Review durchlaufen sollen.
Unabhängig von der Regelmäßigkeit des Code Reviews bleibt eine Frage im Vorfeld meist ungeklärt:
Was passiert mit dem Ergebnis?
Im Idealfall sind sich die Beteiligten einig: Der Code muss angepasst werden. Und der Zeitaufwand der Änderung steht in einem angemessenen Verhältnis zum Ergebnis. Damit steht einer schnellen Anpassung nichts im Wege.
Während funktionale Fehler meist klar identifiziert werden können, stellt sich das Maß "Einfachheit" komplexer dar. Nicht immer kommen Entwicklerinnen und Entwickler in diesem Zusammenhang auf einen Nenner. Unterschiedliche Qualitätsansprüche an die Codequalität sorgen an diesem Punkt für einen intensiven Austausch zwischen den Beteiligten. Die optimale Vorstellung "Wir entscheiden gemeinsam, was der beste Weg ist" funktioniert nicht immer. Uneinigkeit über den besten Weg eine Funktion umzusetzen, kann Euer Projekt blockieren.
Konsens kann hier zur Falle werden. Und das Ergebnis des Code Reviews blockiert. An Stelle, dass der Code besser wird, verheddert Ihr Euch in Ergebnis-Debatten.
Was passiert, wenn sich die Beteiligten über das Review-Ergebnis uneinig sind?
Angenommen der Reviewer beziehungsweise die Reviewerin findet etwas im Code, das aus deren Sicht angepasst werden sollte. Der Code-Ersteller oder die Code-Erstellerin ist in diesem Punkt anderer Meinung. Eine Diskussion über die unterschiedlichen Standpunkte führt nicht zu einem Konsens. Wer trifft die Entscheidung über das weitere Vorgehen?
- Lohnt es sich für die Veränderung des Codes zusätzlichen Aufwand zu investieren und so die Codequalität langfristig zu steigern?
- Oder ist davon auszugehen, dass die Funktion mittelfristig sowieso durch eine andere Lösung abgelöst wird?
Gerade in Teams mit Fluktuation spielt leicht verständlicher Code eine besondere Rolle. Neuen Team-Mitgliedern soll es möglichst einfach gemacht werden, sich in die neuen Themenbereiche einzuarbeiten und schnell dauerhaft produktiv zu werden. Gleichzeitig ist der Faktor "Zeit" in vielen Projekten eine entscheidende Metrik.
Die Entscheidungsfindung in Bezug auf Review-Ergebnisse sollte einer eindeutigen Regelung folgen. Mögliche Regeln können hierbei sein:
- Die Entscheidung über die erneute Code-Veränderung trifft der Code-Ersteller oder die Code-Erstellerin.
- Der Rezensent oder die Rezensentin des Codes trifft die Entscheidung darüber, ob Code-Zeilen verändert werden müssen.
- Eine dritte Person übernimmt die endgültige Entscheidung, wie der Code für die geplante Funktionalität aussehen soll.
- In Streitfragen entscheidet das Team im Konsent, wie zu verfahren ist.
Beim Festlegen der Regel sind zwei Faktoren von großer Bedeutung:
- Alle Beteiligten müssen die Regel kennen.
- Alle müssen verstanden haben, wann und warum sie Anwendung findet.
Einigungsregeln helfen aus der Konsensfalle und machen Pair Reviews zu dem, was sie sein sollen: zu einem ausgezeichnet effizienten Lernort für alle Beteiligten.
- Nächster Artikel: Agiles Coaching | Mit Haltung
- Vorheriger Artikel: Moin Tobias!
Kommentar schreiben