9 Minuten
Warum sollte man Code Reviews im Team durchführen?
‘Hä? Was soll denn das?’ ist ein Satz, den man öfters hört, wenn man mit Systemen arbeitet, die schon ein paar Jahre auf dem Buckel haben und an denen viele verschiedene EntwicklerInnen gearbeitet haben.
Das Ziel regelmäßiger Code Reviews im Team ist es die ‘Hä?’-Momente langfristig auf ein Minimum zu reduzieren, indem wir ein gemeinsames Verständnis für guten Code aufbauen.
Niemand schreibt perfekten Code. Jeder lernt mit der Zeit dazu. Code Reviews im Team geben allen die Möglichkeit voneinander und miteinander zu lernen. Jede EntwicklerIn bringt eine andere Perspektive und eigene Erfahrungen mit. Das führt zu einem unterschiedlichen Verständnis von dem, was ‘guter Code’ in einem konkreten Fall eigentlich bedeutet. Diese unterschiedlichen Sichtweisen zu diskutieren und gemeinsam neue Lösungen und Ideen zu entwickeln, ist der Schlüssel, um langfristig ein gemeinsames Verständnis für guten Code aufzubauen.
Aber…
’…ich kann doch einfach mein Code Review in GitLab durchführen.’ Grundsätzlich sind Code Reviews mit GitLab nützlich und sinnvoll, um Probleme zu finden, eine zweite Meinung einzuholen und Wissen weiterzugeben. Leider hilft dieser Weg nur bedingt ein gemeinsames Gespür für guten Code aufzubauen, Probleme und Fragen zu diskutieren und neue Lösungen zu entwickeln. Damit CodeReviews über GitLab gut funktionieren, sind ein gemeinsames Grundverständnis für guten Code und damit Code Reviews im Team essenziell.
’…das kostet doch viel zu viel Zeit. / … das ist doch ineffizient.’ Ein Code Review durch eine KollegIn wird vielleicht 80% des Ergebnisses für das konkrete Stück Code liefern, aber nicht das Verständnis im Team fördern, warum diese oder jene Variante in dieser Situation besser ist. Sprich, unsere Fähigkeit zukünftig besseren Code zu schreiben entwickelt sich dabei nur eingeschränkt weiter.
’…ich kenne mich da doch gar nicht aus. Was kann ich denn beitragen?’ Schau den Code an und stell Fragen. Alles, was einem seltsam vorkommt oder schwer zu verstehen ist, ist eine Frage wert. Auch wenn man ein unbekanntes Konstrukt sieht, einfach fragen. Oft führen gerade solche Fragen zu wichtigen Diskussionen, bei denen alle etwas lernen können.
Wie sieht ein Code Review im Team aus?
Um Code Reviews im Team für alle angenehm und produktiv zu gestalten gibt es ein paar Regeln, die von allen eingehalten werden müssen. Das betrifft die Vorbereitung, die Auswahl des Codes, den konkreten Ablauf und die Etikette.
Wie müssen sich Teilnehmer vorbereiten?
Alle kommen vorbereitet zum Termin. Damit die Zeit im Termin produktiv genutzt werden kann, müssen alle Teilnehmer ihre Fragen und Kommentare zum Code vorbereitet haben.
Jeder Teilnehmer nimmt sich 30-60 Minuten Vorbereitungszeit, um sich in den Code einzulesen und seine Fragen und Verbesserungsvorschläge zu notieren. Weniger als 30 Minuten reicht meist nicht, um sich ernsthaft mit dem Code auseinanderzusetzen. Mehr als 60 Minuten führen meist nicht zu besseren Ergebnissen.
Wie müssen sich Autoren vorbereiten?
Die AutorIn verschickt vorab eine Einladung mit kurzer Erklärung. Welche Klassen / Methoden sollen gereviewed werden? Wo ist der beste Einstiegspunkt? Was sollte fachlich mit den Änderungen erreicht werden? Gibt es offene Punkte/Fragen? Es ist extrem wichtig den richtigen Rahmen zu setzen und den Reviewern die Prioritäten mitzugeben.
Keinen fertigen Code reviewen. Es kommt immer wieder vor, dass die AutorIn alles richtig machen möchte und deshalb ein Stück Code auswählt, das schon längst fertig ist. Das ist KEINE gute Idee.
-
Es tut unglaublich weh an diesem Code wieder Änderungen und Anpassungen machen zu müssen. Meist ist dafür keine Zeit eingeplant.
-
Es ist weniger schlimm, wenn der eigene Code - von dem man weiß, dass er noch nicht fertig ist - kritisiert wird, als ein Stück Code bei dem man sich unglaublich viel Mühe gegeben hat und das man eigentlich für gut hält. Erfahrungsgemäß ist es so, dass es Feedback gibt, egal wie sehr man den Code selbst geschliffen hat.
-
Man kann als Autor selbst Fragen mit ins Review bringen. ‘Ich habe folgendes Problem und bin mir nicht ganz sicher wie eine gute Lösung aussieht. Was meint ihr?’ Das führt automatisch zu konstruktiven Diskussionen.
Kurz gesagt: Nicht drei Wochen an einer Sache herumbasteln und es unnötig polieren. Außerdem Zeit einplanen, um die Vorschläge später einarbeiten zu können.
Weniger als 400 Zeilen Code pro Review. Es ist wichtig die Menge des zu reviewenden Codes zu begrenzen, da sonst die Qualität des Reviews und der Diskussion abnimmt. Bei mehr als 400 Zeilen Code nimmt die Fähigkeit weitere Fehler und Probleme zu finden stark ab [1]:
Abbildung 1: Fehlerdichte beim Code Review [[1]]
Wie läuft der Termin ab?
Teilnehmerkreis sollte überschaubar sein und sich auf 4-7 Personen beschränken. Je mehr Personen an einem Review teilnehmen, desto weniger wird offen diskutiert.
Eine neutrale Person präsentiert den Code und moderiert die Session. Es ist essenziell, dass NICHT der Autor den Code präsentiert und die Session moderiert. Ein neutraler Moderator kann viel besser auf Redezeiten achten und wird sich nicht so schnell in emotionale Diskussionen verstricken. Ganz im Gegenteil, er greift ein, wenn eine zu intensive Diskussion entsteht.
Der Termin ist auf 60 Minuten begrenzt. Das fühlt sich manchmal so an, als würde man mitten in der Diskussion abbrechen, dennoch ist es nachweislich so, dass danach die Effektivität stark abnimmt [1].
Der Autor protokolliert die Anmerkungen. Die Teilnehmer können ihm natürlich ihre Kommentare noch gesondert zuschicken. Üblicherweise bietet es sich an im Review selbst nur die wichtigsten Punkte zu besprechen. Kleinigkeiten wie Typos etc. können dem Autor einfach im Nachgang zugeschickt werden.
Start mit einem 2 Minuten Blitzlicht. Der Autor beginnt mit einer kurzen Vorstellung des Codes und erläutert seine Überlegungen und offenen Punkte. Anschließend stellt jede TeilnehmerIn in maximal 2 Minuten ihre 2-3 wichtigsten Anmerkungen oder Fragen zum Code vor. Es geht dabei darum einen ersten Eindruck von den wichtigsten Punkten zu bekommen. Zu diesem Zeitpunkt wird nicht diskutiert.
ModeratorIn geht die wichtigsten Punkte durch. Anschließend geht die ModeratorIn die wichtigsten Punkte durch und moderiert die Diskussion zu den unterschiedlichen Themen.
Übergang in gemeinsames Coding. Gegebenenfalls bietet es sich an, bei einzelnen Punkten direkt ins Refactoring zu gehen und den Code (beispielhaft) anzupassen.
Was ist sonst noch wichtig?
Gegenseitiger Respekt, kein Sarkasmus. Das sollte selbstverständlich sein. Wir wollen alle etwas lernen. Es ist viel Arbeit in den Code geflossen. Darum ist es nur fair der AutorIn den notwendigen Respekt entgegenzubringen.
Immer erst etwas ernsthaft Positives zum Code sagen. Wir neigen oft dazu uns zu sehr auf die Probleme und Ungereimtheiten zu stürzen. In den meisten Fällen gibt es aber auch Dinge, die gut gelöst worden sind. Es ist wichtig auch diese explizit zu machen.
Fazit
Code Reviews im Team sind wie Workouts. Erst hat niemand richtig Lust darauf und man fragt sich, ob man es überhaupt machen sollte. Sobald man angefangen hat, beginnt es Spaß zu machen. Plötzlich ist die Stunde vorbei und man ist enttäuscht aufhören zu müssen. Alle sind froh das Review gemacht zu haben und reden noch ein paar Tage davon wie gut die Diskussion war.
Wir sind alle nur Menschen und haben unglaublich viel zu tun. Es lohnt sich aber hier dranzubleiben und ein paar mal zu probieren, auch wenn es sich zu Anfang seltsam anfühlt.
