Code Reviews

31.12.2018

Warum es sich lohnt, Gedanken über Code Reviews zu machen

Bis vor kurzem dachte ich eine Code Review sei keine komplizierte Sache. Ein Kollege setzt sich zu mir an den Arbeitsplatz, wir gehen gemeinsam meinen Code durch und ich notiere mir, was ihm dabei auffällt. Anschließend beseitige ich sämtliche Fehler und Missstände, benenne Variablen um, führe Refactoring durch und füge weitere Tests hinzu. Was sich in der Theorie so einfach liest, scheint in der Praxis nicht so leicht umsetzbar zu sein. Mit dem Webinar „Code Review Best Practices“ von Trisha Gee ist mir erst aufgefallen, wie umfangreich das Thema ist und was man dabei alles falsch machen kann. Was sie als Anti Pattern bezeichnet, habe ich ehrlicherweise selbst schon erlebt, aber nicht erkannt.

Wie sollte eine Code Review aussehen?

Nur zu oft lassen sich Fragen in unserer Branche mit „it depends“ beantworten und dieses hier ist ebenso der Fall. Aber wovon hängt es ab? Grundsätzlich muss man feststellen, dass sich drei verschiedene Arten identifizieren lassen, die verschiedene Anforderungen und Rahmenbedingungen stellen:

  • Design Feedback Reviews
  • Gateway Reviews
  • Knowledge Sharing Reviews

Design Feedback Reviews finden während der Implementierung statt und sollen sicherstellen, dass der Entwickler sich auf dem richtigen Weg befindet. Je später ein Fehler im Design auffällt, desto teurer und schwerer wird die Änderung, weshalb diese Reviews möglichst früh und oft durchgeführt werden sollten. Wie oft, ist dabei sowohl abhängig von der Größe der umzusetzenden Aufgabe als auch von der Erfahrung des Entwicklers.


Bei der Gateway Review handelt es sich um die „klassische“ Variante, wie ich sie einleitend bereits beschrieben habe. Es ist als eine Art Kontrolle zu verstehen, die bestanden werden muss, bevor der Code in Produktion geht oder gemergt werden kann. Bevor man eine manuelle Review durchführt, sollte der Code vorher mithilfe eines Tools automatisiert überprüft werden. In meinem aktuellen Projekt verwenden wir beispielsweise Sonar, das sich prima in den Continous Integration Prozess integriert und bei jedem Build auf dem Jenkins ausgeführt wird. Auf diese Weise wird sichergestellt, dass sämtlicher Code den Entwicklungsrichtlinien entspricht und der Reviewer keine Zeit dafür aufbringen muss, um nach falschen Einrückungen oder Ähnlichem zu suchen. Dafür ist unsere Zeit zu wertvoll! Vielmehr sollte er nach allem Ausschau halten, was eben nicht automatisiert werden kann, beispielsweise:

Entspricht der Code den Standards? Dies setzt natürlich voraus, dass vorher Standards definiert wurden. Wenn Vorgaben existieren, festgehalten wurden und dem Entwickler als auch dem Rezensenten bekannt sind, führen sie zu einer höheren Softwarequalität und erleichtert den Prozess der Review.

Ist der Code verständlich? Für diesen Punkt lohnt es sich einen Junior Entwickler ins Boot zu holen. Anfänger sind weniger vorbelastet, können sich Beziehungen noch nicht so leicht herleiten, wie es bei jemandem mit mehreren Jahren Berufserfahrung der Fall ist. Vielleicht kann man sogar einen Nutzen daraus ziehen, da sie mehr Fragen stellen und so Lücken aufdecken könnten.

Werden die Anforderungen erfüllt? Der wohl schwierigste Teil wird es sein, funktionale und fachliche Anforderungen zu überprüfen. Hier kann ein Blick in die Tests Aufschluss darüber geben, ob alle Aspekte betrachtet wurden oder Nachholbedarf besteht.


Die letzte der drei Arten, die Knowledge Sharing Review, dient dazu, das Wissen auf das gesamte Team zu verteilen und Informationssilos zu vermeiden. Ziel sollte es sein, dass jeder Entwickler den gesamten Codestand kennt und für einen Kollegen einspringen kann. Dieses Meeting ist ein reiner Informationsaustausch, der Code wurde bereits abgesegnet, es finden keine Änderungen statt.

Wie eine Review nicht aussehen sollte

Wo es Good Practices gibt, findet man unweigerlich auch Bad Practices. Da wir bei einer Code Review die Arbeit eines Kollegen unter die Lupe nehmen, bedarf es etwas Fingerspitzengefühl. Kleinigkeiten anzumeckern ist eher kontraproduktiv und schadet der Motivation. Genauso sollten in einer Gateway Review keine Änderungen am Design vorgeschlagen werden, wenn der Code funktioniert. Der richtige Zeitpunkt dafür ist während der Implementierung. Ebenso ist es ein Problem, wenn verschiedene Rezensenten ein unterschiedliches Verständnis davon haben, wonach sie in der Review suchen sollen. Für den Entwickler sollte es klar sein, was auf ihn zukommen kann. Ein weiterer Punkt, der vermieden werden sollte, sind nicht enden wollende Reviews oder „Ping Pong Reviews“ wie Trisha sie nennt. Es muss unbedingt klar sein, was der Entwickler nachzubessern hat und wann die Review komplett beendet ist. Hier könnte eine Definition of Done hilfreich sein. Außerdem sollten Reviews möglich zeitnah abgehalten werden. Je mehr Zeit vergeht, desto schwieriger wird es, sich wieder in den alten Code hineinzudenken. Als letztes Anti Pattern möchte ich das Verfehlen des Review-Ziels aufbringen: Ziel sollte es sein, die Qualität des Codes abzusichern. Unter keinen Umständen geht es um die Bewertung des Kollegen, man darf also nicht die Gelegenheit dazu nutzen, um zu zeigen, dass man ein besserer Programmierer ist.

Wenn wir auf diese Anti Pattern achten, können wir es vermeiden, dass eine negative Haltung gegen Code Reviews entsteht.

http://www.geek-and-poke.com

Zusammengefasst

… lässt sich sagen, dass es durchaus lohnenswert ist, sich ein paar Gedanken über Code Reviews für das eigene Projekt zu machen, mit dem Team zu besprechen und festzuhalten. Alle Teilnehmer sollten den Nutzen kennen, um das große Ziel, das wir alle verfolgen, nie aus den Augen zu verlieren: gute, qualitative Software zu schreiben.

Als nächstes möchte ich einen Review-Plan für das aktuelle Projekt, in dem ich derzeit arbeite, erstellen und nach einer Erprobungsphase davon berichten.

Es interessiert mich allerdings auch, wie eure Erfahrungen mit Code Reviews sind. Bitte schreibt mir in den Kommentaren, wie ihr eure Reviews abhaltet, wie oft und wann. Oder habt ihr gar keine Reviews, weil euer Projektleiter sie für unnötig und zeitaufwendig hält? Ich freue mich auf euer Feedback.

Das volle Webinar von Trisha Gee mit rund einer Stunde länge gibt es unter

https://blog.jetbrains.com/upsource/2018/10/16/webinar-recording-code-review-best-practices/

Zurück zur Übersicht

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

*Pflichtfelder

*