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.