Nachfragen statt urteilen: 4 Gedankenanstöße für effektive Code Reviews

My code is guaranteed 100% mistrake free.

Das Arbeiten mit Pull Requests und Code Reviews gehört bei synyx zum Alltag. Neuer Code fließt normalerweise erst dann in den Hauptzweig eines Projekts, sobald er ein Review durchlaufen hat. Selbstverständlich kann es berechtigte Ausnahmen geben. Zum Beispiel bei Code, der komplett im Pair Programming erstellt oder lediglich durch einen winzigen Fix verändert wurde.

Code Reviews sind nicht als bürokratisches Kontrollwerkzeug zu betrachten, sondern als wirksames Hilfsmittel zur Verbesserung der Qualität nach dem Prinzip: Vier Augen sehen mehr als zwei.

Fernab von Technik und Tools möchte ich im Folgenden vier Gedankenanstöße für effektive Code Reviews liefern.

1. Eine bewusste Entscheidung?

Gut:
“Diese Variable sollte nicht public sein.”

Besser:
“Wieso hast du dich dafür entschieden, diese Variable public zu machen?”

Die erste Herangehensweise führt lediglich zur Anpassung des Scopes von genau einer Variable. Die zweite Herangehensweise hingegen bietet Raum für tiefergehende Erkenntnisse. Es kann eine lehrreiche Diskussion über die Sichtbarkeit von Variablen entstehen. Es kann aber auch sein, dass die Konfiguration der Entwicklungsumgebung angepasst wird. Vielleicht hat der Entwickler den Scope für die Variable gar nicht bewusst gewählt, sondern lediglich übersehen, dass seine IDE unpassenden Boiler Plate Code generiert hat.

2. Zu kurz gedacht?

Gut:
“Das funktioniert so nicht.”

Besser::
“Wieso hast du das Problem auf genau diese Weise gelöst und nicht anders? Hast du Edge Case XY eigentlich bedacht?”

Im besten Fall schreibt ihr gemeinsam einen Test für den nicht abgedeckten Edge Case und optimiert den Code im Teamwork. Vielleicht findet sich aber auch ein guter Grund, wieso das Problem genau so gelöst wurde. Es muss nicht immer der Autor zu kurz gedacht haben, manchmal kann auch der Reviewer einen Aspekt übersehen haben. Durch Fragen entstehen Diskussionen, die zu neuen Erkenntnissen und Wissenstransfer führen können.

3. Wie soll ein Junior einem Senior schon helfen?

Gut:
“Puh, das verstehe ich jetzt nicht wirklich. Naja, wird schon passen.”

Besser:
“Ich verstehe diese Stelle im Code nicht so ganz. Kannst du mir das genauer erklären?”

Als Junior den Code eines Seniors zu reviewen ist doch sinnlos, oder? Nein, ganz im Gegenteil. Beide Seiten profitieren gleichermaßen. Der Junior kann eine ganze Menge dabei lernen, zu sehen, wie ein gestandener Entwickler ein bestimmtes Problem löst. Der Senior wiederum profitiert vom frischen Blickwinkel des Juniors. Womöglich wurde die ein oder andere Stelle im Code derart überoptimiert, dass andere Teammitglieder sie nur noch schwer nachvollziehen können. Vielleicht fehlen erklärende Kommentare als Hilfe. Durch gezielte Verständnisfragen kann der Junior zu besser wartbarem Code beitragen, gerade weil er wenig Erfahrung mitbringt. Abgesehen davon macht auch der erfahrenste Entwickler Flüchtigkeitsfehler, die durch ein zweites Paar Augen ausgemerzt werden können.

Verläuft das Code Review in umgekehrter Richtung, profitiert der Junior langfristig mehr, wenn der Senior ihm das Problem nur aufzeigt, statt vorgefertigte Lösungshäppchen zu servieren. Durch die richtigen Fragen entsteht Raum zur Erschließung eigener Lösungswege und damit ein langfristiger Lerneffekt.

4. Über Geschmack lässt sich (nicht) streiten?

Gut:
“Ich kann While-Schleifen nicht ausstehen.”

Besser:
“Wieso hast du hier eine While-Schleife benutzt und keine For-Schleife?”

Natürlich sollten sich alle Teammitglieder an gemeinsam festgelegte Konventionen und Best Practices halten. Trotz allem hat jeder Entwickler seinen eigenen individuellen Stil. Solange dieser nicht gegen die vereinbarten Konventionen verstößt, spricht doch nichts dagegen, die individuellen Vorlieben zu akzeptieren, oder? Durch neugieriges Nachfragen erfährt man vielleicht sogar, ob bestimmte Motive hinter einer Stilrichtung zur Problemlösung stecken.

Nachfragen statt urteilen!

Das gilt definitiv nicht nur für Code Reviews. Selbst in enger Zusammenarbeit innerhalb eines Teams sehen wir immer nur gewisse Momentaufnahmen unserer Mitmenschen. Wir können bloß Vermutungen anstellen, aber nie hundertprozentig sicher sein, wieso jemand tut, was er tut, oder wie seine Äußerungen wirklich gemeint sind. Durch zeitnahes Nachfragen lassen sich kleine Ärgernisse und potentielle Missverständnisse schnell aus dem Weg räumen, anstatt sich mit der Zeit zu einem monströsen Konflikt anzustauen.

Wenn du also das nächste Mal Ärger in dir aufsteigen spürst, spreche lieber die betreffende Person auf ihr Verhalten an, statt vorschnell zu urteilen und dich (innerlich) aufzuregen.

Vielleicht ist ja alles ganz anders, als du denkst 😉

Hinweis: Aus Gründen der Lesbarkeit habe ich im Text ausschließlich die männliche Form benutzt, nichtsdestotrotz beziehe ich mich immer auf Angehörige aller Geschlechter.