Blog

Wie Sie Code Reviews effektiv und zielführend halten

Code Reviews – der nicht-technische Part

Gespräche über das Thema Code Review münden häufig in eine Diskussion à la <Fancy-Tool> ist viel besser weil <cooles-feature>. Dabei gibt es bei Code Reviews wesentlich mehr zu beachten, als das richtige Tool und die Einhaltung der Naming-Conventions.

In dieser Reihe gehe ich auf die nicht-technischen Aspekte von Code Review ein. Beginnen möchte ich mit einem Überblick, warum Code Reviews sinnvoll sind, welche Geschmacksrichtungen es gibt und wie sie in die tägliche Arbeit eingebunden werden können.

 

Eine gute Definition des Begriffs Code Review ist aus meiner Sicht:

Code review is a systematic examination (sometimes referred to as peer review) of computer source code. It is intended to find mistakes overlooked in the initial development phase, improving the overall quality of software. Reviews are done in various forms such as pair programming, informal walkthroughs, and formal inspections.

Besonders wichtig finde ich die „systematic examination of source code“ und das übergeordnete Ziel „improving the overall quality“.

 

Eine systematische Betrachtung von Source Code klingt einleuchtend. Doch wie kann eine solche aussehen? Nun, es gibt verschiedene Arten um ein Code Review durchzuführen.

Grundsätzlich unterscheidet man zwischen Pre-Commit und Post-Commit. D.h. das Review wird durchgeführt, bevor Quellcode committed wird oder nachdem der Commit in der Versionsverwaltung angekommen ist. Welchen Weg Sie wählen kommt auf Ihren Entwicklungsprozess an.

Zum zweiten lässt sich Code Review unterteilen in einen automatischen Review und einen manuellen Prozess. Ein automatischer Review kann z.B. durch statische Codeanalyse erfolgen. Darauf möchte ich hier nicht weiter eingehen, das würde den Beitrag sprengen.

 

Möglichkeiten im manuellen Prozess bei Code Reviews

 

Der manuelle Prozess ist aus meiner Sicht der spannendere und darauf werde ich mich in diesem Beitrag konzentrieren.

Die einzelnen Geschmacksrichtungen beim manuellen Review unterscheiden sich primär darin, wie viele Personen beteiligt sind und in welchem Stadium der Entwicklung das Review abläuft.

Beim Pair-Programming wird der Code bereits betrachtet, noch während er geschrieben wird. Hier passiert das Review sehr früh im Prozess, was sich positiv auf die Time-to-Market auswirken kann, da der Commit bereits qualitätsgesichert ist.

Zeitlich nach hinten verlagert ist das Peer Review (häufig auch als Code Review bezeichnet), bei dem Entwickler und Reviewer den geschriebenen Code betrachten. Falls es sich nicht um einen Review sondern z.B. das ganze Team handelt, wird dies als Inspection oder Team-Review bezeichnet.

Feature-Branch-Review, Pull Request und Merge Request sind zeitlich noch später angesiedelt. Hier wird das Review durchgeführt, nachdem ein Feature vollständig entwickelt wurde und fertig zur Integration ist.

 

Das passende Review für Sie finden

 

Welcher Ansatz für Sie der Geeignetste ist, kann nicht pauschal beantwortet werden. Je früher das Feedback kommt, desto eher kann es implementiert und eine falsche Richtung vermieden werden. Und je mehr Projektbeteiligte Feedback geben, desto besser und umfassender die Lösungen. Pair-Programming mit dem gesamten Team hat sicherlich das Potential der höchsten Qualität, jedoch auch einen ordentlichen Preis.

Bedenken Sie die Auswirkungen und experimentieren Sie im Rahmen Ihrer organisatorischen Leitplanken!

Wie können nun Code Reviews in Bezug auf „improving the overall quality“ helfen?

 

Durch ein Review noch innerhalb des Entwicklungsprozesses werden Fehler bereits gefunden und behoben, noch bevor die Software auf Test/QA ausgeliefert wird. Zudem lässt sich mittels Code-Diskussion das Know-how zum System und deren Bestandteile besser verbreiten, was zu einem besseren Verständnis des Systems bei den Entwicklern führt. Auch steigt dadurch die Identifikation mit dem gesamten Code und es wird ein collective code ownership erreicht.

Indem über Code gesprochen wird, ergeben sich automatisch Regeln und Konventionen, d.h. der Code wird konsistenter und damit wird auch eine Einarbeitung leichter.

Sie sehen, Code Reviews haben nicht nur einen positiven Effekt auf die Qualität der Software, sondern auf den gesamten Entwicklungsprozess und auch auf das Team. Wenn Sie es richtig machen!

Und dazu komme ich im zweiten Teil der Reihe, doch auch da bleibe ich der Technik fern.

Die sozialen Aspekte beim Code Review

 

Reviewer wie auch Entwickler sollten sich einiger psychologischer Effekte bewusst sein, um ein Code Review als etwas Positives zu erleben.

Als Entwickler muss man sich regelmäßig bewusst machen, dass jeder Mensch Fehler macht. Und jeder hat mal einen dieser Tage, an dem man besser keinen Commit macht. Daher ist es gut und sinnvoll, dass sich ein anderer Entwickler die Änderungen ansieht und kommentiert, um das übergeordnete Ziel „improving the overall quality“ zu erreichen.

Software Entwicklung wird manchmal als eine spezielle Form von Kunst bezeichnet und so hat auch mancher Entwickler eine innige Bindung zu seinem Code. Diese Bindung kann einem konstruktiven Review entgegenstehen, daher der zweite Hinweis für Entwickler: you are not your code!

Ein dritter Punkt ist, egal wie viel ich als Entwickler über Software und Technik zu wissen glaube, es gibt immer jemanden, der mehr weiß und andere Erfahrungen gemacht hat. Das Wissen und die Erfahrung des Reviewers kann ich als Entwickler nutzen, um mich selbst weiter zu entwickeln.

Grundregeln für Reviewer

 

Im Code Review Prozess ist die Position egal. Kompetenz bzw. Autorität kommt allein aus dem Wissen und der Erfahrung. D.h. die Lösung des Lead Entwicklers ist nicht automatisch die Beste!

Code Review ist auch Feedback und kann daher leicht als (persönliche) Kritik aufgefasst werden, wenn sie ungeschickt formuliert wird. Daher ist es als Reviewer wichtig, einzig den Source Code zu kritisieren, nicht aber den Autor des Codes.

Eine hilfreiche Herangehensweise für Code Reviews ist „ask, don’t tell“. Das bedeutet, zuerst den Grund für eine Lösung zu verstehen statt direkt eine alternative Lösung zu diktieren. Um einen Vergleich zu ziehen: Würden Sie eine ärztliche Diagnose akzeptieren, die ohne ein vorheriges Gespräch entstanden ist?

 

Neben dem richtigen Mindset möchte ich Sie noch auf potentielle Effekte hinweisen, derer man sich bewusst sein sollte:

  • Änderungen mit 10 Codezeilen bekommen 15 Änderungsvorschläge … 500 Codezeilen hingegen nur ein „sieht gut aus“
  • Das eigene Ego … oder: der schmale Grad zwischen persönlicher Vorliebe und hässlichem Code
  • Teddybär-Effekt: Der Entwickler ist ein echt cooler Typ, dessen Arbeit ich nicht kritisieren möchte
  • Code Review wird langweilig und nervig bzw. …
  • … man sieht den Wald vor lauter Bäumen nicht mehr.

Wie Sie Code Reviews effektiv halten

 

All diese Effekte gefährden das übergeordnete Ziel „improving the overall quality“. Sie zu erkennen ist meist schon fast die Lösung, so dass Code Reviews effektiv bleiben.

Generell ist zu empfehlen, die Dauer eines Reviews und die Lines-of-Code zu beschränken. Erfahrungswerte zeigen, dass man max. 60 bis 90 Minuten am Stück daran arbeiten sollte – abhängig davon, wie sich die beteiligten Menschen dabei fühlen. Die maximale Anzahl an Codezeilen hängt sehr von Projekt und Programmiersprache ab. Hören Sie auf Ihr Inneres und das Ihres Review-Partners, um zu erkennen wann eine Pause oder ein anderer Ansatz sinnvoll ist.

Ebenfalls empfehlen kann ich Checklisten, um mich an wichtige Aspekte und Regeln zu erinnern. So mancher hat eine angeborene Aversion gegen Checklisten, ich finde sie als Brain-Dump jedoch sehr hilfreich.

Auch statische Codeanalyse ist eine Art von Code Review, daher nutzen Sie gerne die Möglichkeit der automatischen Prüfung von vereinbarten Regeln. Dies hat den Vorteil des zeitnahen Feedbacks und kostet weniger Zeit/Aufwand als ein manuelles Review.

 

Zu guter Letzt möchte ich doch noch ein paar Worte zu Code Review Tools verlieren: Wählen Sie ein Tool, dass zu ihren Prozessen und zu ihrer Organisation passt. Achten Sie bei der Nutzung eines Tool bitte darauf, dass die persönliche Zusammenarbeit nicht leidet!

Hoffentlich konnte ich Ihnen in dieser kleinen Reihe einen Einblick und hilfreiche Hinweise geben um Ihr Code Review angenehmer und effektiver zu gestalten. Ich freue mich über Feedback und Anregungen in den Kommentaren!



Keine Kommentare

Hinterlassen Sie einen Kommentar

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