Artikelformat

Code Peer Reviews – ein Rückblick

Vor einigen Wochen habe ich hier verschiedene Arten der Code Reviews vorgestellt. Zur Einführung von Code Reviews gibt es heute einen kurzen Rückblick. Was sollte man bei der Einführung beachten und was sollte man auf keinen Fall tun.

Grundsätzlich sind Entwickler von Code Reviews immer begeistert. Jeder möchte einem Kollegen zeigen, welch genialen Einfall man hatte und wie elegant ein Problem gelöst wurde. Auch zeigt man gerne ein Problem, das man bisher nicht lösen konnte, um eine zweite Meinung einzuholen. Somit ist die Akzeptanz bei den Entwicklern sehr hoch und es besteht kein grundsätzlicher Widerstand gegen das Vorgehen.

Ein wichtiger Faktor (insbesondere für das Management) ist die Zeit. Code Reviews kosten Zeit und das sogar doppelt, da 2 Entwickler beschäftigt sind. Daher möchte man gerne planen können, wieviel Zeit verbraucht wird und wer, wann im Review steckt. Dieses Problem lässt sich ganz einfach lösen. Man erlaubt jedem Entwickler eine festgelegte Stunden-Kontingent monatlich für Peer Reviews zu verbrauchen. Der Rest wird vom Entwickler-Team selbst organisiert. So kann der Entwickler vernünftig „verplant“ werden, aber die Freiheit ein Peer Review durchzuführen besteht immer noch. Durch das Kontingent sollten die Reviews auch nicht ausufern.

Weiter sollte ein Leitfaden von den Entwicklern definiert werden. So kann ein neuer Kollege sehr einfach in das Peer Review-Vorgehen finden und sich leichter einbringen. Und die Peer Reviews sind normalisiert. Es gibt ein minimales Subset, das auf jeden Fall betrachtet wurde. Aus diesem Grund sollte ein solcher Leitfaden aber auch nicht zu umfangreich ausfallen. Sinnvoll ist vor allem die automatischen Tests und Überprüfungen, die der CI-Server durchführt, zu ergänzen. Bspw Codestellen, die automatisch identifiziert wurden, sollten vom Mensch nachkontrolliert und Lösungen gefunden werden.

Welche Entwickler sollten ein Review durchführen? Im optimalen Fall schauen sich zwei Entwickler mit ähnlichem Wissensstand in der gleichen Programmiersprache den Code an. Damit wird man den Code optimal verbessern können. Möchte man sich als Entwickler verbessern, so sollte man einen besseren Entwickler als Peer – Partner suchen. Zu vermeiden ist ein zu großer Wissensunterschied, denn dann wird es eine sehr einseitige Vorstellung.

Weiter ist es auch optimal, wenn beide Entwickler am gleichen Projekt arbeiten. Dann müssen Grundlagen nicht zu sehr kommuniziert werden und man kann sich auf den Code konzentrieren. Ein projektfremder Entwickler muss zuerst in die Umstände des Projekts eingeführt werden und somit transferiert man zwar Projektwissen, der Code kommt aber zumeist zu kurz.

2 Kommentare

  1. Jan Markmann

    15/09/2010 @ 15:23

    Ich hab grad sowas abgeschlossen, allerdings in größerem Umfang als nur <=300 Zeilen, ein ganzes Projekt. Könnte man schon fast Audit nennen aber auch die ist ja zumindestens in Teilen eine Code-Review.
    Zu mindestens wenn es um einen größeren Umfang oder eine nicht ganz so häufige aber allumfassende Review geht finde ich es sogar von Vorteil nicht am Projekt beteiligt gewesen zu sein. So denkt man sich frisch in die Aufgabenstellung rein und bringt eine neue Sichtweise mit. Dadurch fallen Sachen auf, die sich bisher im Projekt als selbstverständlich verstanden und gar nicht mehr hinterfragt wurden.
    Auch ist es gar nicht so verkehrt mal großen Teile zu analysieren, bis hin zum ganzen Projekt. Nur so findet man dann auch zuverlässig doppelte Implementierungen und Co.
    Mein Vorgehen war auch etwas anders: einen Partner hatte ich nicht zur Verfügung. Daher habe ich alles wozu man Insiderwissen bräuchte zum Verstehen erst mal markiert und später in kurzen Gesprächen mit einem Projektprogrammierer erläutert.
    Um dem Umfang der verschiedenen Fehler/Verbesserungen Herr zu werden habe ich noch eigene Task Tags verwendet wie //REFACTOR und //REVIEW und Ergebnisse in einer Textdatei gesammelt, die sich nicht mit Task Tags alleine ausreichend beschreiben lassen.
    Das ganze hat mich gut eine Woche Arbeit gekostet für ca 504k Code.
    Dürfte schneller gehen wenn der Code nicht ganz so verkorkst ist. In diesem Fall war es ein halbfertig gestelltes Projekt welches wieder aufgetaut wurde nachdem es vor Monaten auf Eis gelegt wurde und die Qualität war generell, naja sagen wir mal semioptimal.
    Das mag auch Grund für das konkrete Vorgehen gewesen sein. Generell find ich es aber schon eine gute Idee den betrachteten Bereich mal weit zu fassen und auch mal eine ganz außenstehende Sichtweise zu nehmen.

    Antworten
    • Ich begreife Code Peer Review als Teil des Entwicklungsprozeß eines Features. Ebenso wie die QK Anforderungen an ein Feature stellt, sollte es eben auch von anderen Entwicklern angeschaut werden.

      Das von dir beschriebene Vorgehen würde ich auch eher als Audit bezeichnen und in diesem Fall ist es sehr gut, wenn ein Entwickler den Code anschaut, der nicht aus dem Projekt oder sogar nicht aus der gleichen Firma kommt. Entspricht also deiner Erklärung.

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.