Code-Reviews

Code-Reviews helfen die Code-Qualität zu heben, Bugs zu vermeiden und Wissen zu verbreiten. Mit dem Review Board lassen sich Code-Reviews in den alltäglichen Softwareentwicklungsprozess integrieren.

Code-Reviews kosten Zeit, daher ist die folgende Frage gerechtfertigt: Was bringen Code-Reviews?

  • Bugs frühzeitig erkennen. Je früher im Softwareentwicklungsprozess ein Bug gefunden wird, desto schneller kann er behoben werden und desto weniger kostet die Behebung. Ein Bug in der Produktion benötigt neben dem Bugfix zusätzliche Tests und Deployments. Ein im Code-Review gefundener Bug benötigt nur einen zusätzlichen Commit. In Facts and Fallacies of Software Engineering zitiert Robert Glass verschiedene Studien, nach denen bis zu 90% der Bugs in Code-Reviews gefunden werden können.
  • Höhere Code-Qualität. Einerseits sehen vier Augen mehr als zwei, und andererseits kann ein Reviewer mit mehr Erfahrung einem unerfahreneren Entwickler Hinweise geben.
  • Wissensverteilung. Der Reviewer lernt den geschriebenen Code kennen und kann diesen Code daher besser weiterentwickeln. Außerdem kann der Reviewer Lösungsmöglichkeiten kennen lernen, auf die er selbst nicht gekommen wäre, und sich so selbst weiter entwickeln.

Bugs zu vermeiden ist für jedes Projekt wichtig, die anderen zwei Punkte vor allem für Projekte, die immer wieder weiterentwickelt werden.

Es gibt verschiedene Wege Code-Reviews zu organisieren. Code-Reviews können in persönlichen Gesprächen durchgeführt werden. Dabei stellt Pair Programming die intensivste und direkteste Form dar. Eine andere Möglichkeit sind Review-Meetings, an denen mehrere Entwickler gut vorbereitet teilnehmen. Für schriftliche Code-Reviews sind Werkzeuge notwendig, die dem Reviewer einen Überblick über getätigte Code-Änderungen geben und ihm ermöglichen Feedback zu geben. Erst damit ist eine effiziente Kommunikation über Code möglich.

Wir verwenden dazu das Review Board. Einen ersten Eindruck vermitteln die folgenden zwei Screenshots vom Dashboard und vom Diff-Viewer:

Das Dashboard zeigt die noch zu bearbeitenden Code-Reviews an. Im Diff-Viewer kann man Kommentare zum geänderten Code abgeben und Issues erstellen. Unser Review Board ist mit dem SVN verbunden und organisiert für jeden Commit ein Code-Review. Das folgende Diagramm zeigt den typischen Ablauf eines Code-Reviews bei uns (RB steht dabei für Review Board):

Ein Code-Review wird von einem Entwickler (Submitter genannt) angefordert, indem er in der Commit-Message des neuen Codes mit reviewer: den Reviewer angibt, zum Beispiel changed foo. reviewer:cp (jeder Entwickler hat bei uns ein Kürzel). Abhängig von der Commit-Message wird also ein bestimmter Entwickler über den Review-Request per Email und im Dashboard des Review Board informiert.

Der ausgewählte Reviewer macht möglichst bald sein Review. Daher haben Code-Reviews bei uns Vorrang gegenüber dem Schreiben neuen Codes. Entweder der Reviewer ist zufrieden, dann kann er den Review-Request gleich schließen. Oder er hat Fragen beziehungsweise Verbesserungsvorschläge, die er als Issues zum Review meldet. Diese muss der Submitter dann beantworten oder durch einen weiteren Commit umsetzen. Die weiteren Commits werden zum selben Code-Review dazugehängt, indem der Submitter in der Commit-Message mit updatereview:XY angibt, dass der Commit zum Review mit der Nummer XY gehört. Wenn alle Issues gefixt sind und der Reviewer zufrieden mti der Umsetzung ist, dann schließt er den Review-Request.

Neben dem technischen und organisatorischen Aspekt spielt auch der menschliche Aspekt eine wichtige Rolle bei Code-Reviews. Jedes Code-Review ist Kritik am Submitter. Daher ist es wichtig, dass Anmerkungen als Verbesserungshinweise formuliert werden, und nicht als Feststellungen, dass etwas “falsch” gemacht wurde. Guter Code soll gelobt werden, damit es nicht nur negatives, sondern auch positives Feedback gibt. Zu guter Letzt hilft es sowohl dem Reviewer als auch dem Reviewten das eigene Ego und den eigenen Stolz bei Code-Reviews einzubremsen, um offen zu sein für die Lösungen und Ideen des anderen.

Im nächsten Artikel möchte ich die Integration des Review Boards ins SVN mit Hilfe eines SVN-Hooks detailliert beschreiben. Jetzt aber interessiert mich noch, welche Arten von Code-Reviews du beim Programmieren schon kennen gelernt hast und welche Form dir am besten gefällt. Ich bin gespannt auf deine Meinung!

Andreas Hubmer
(Software Architect)