Im ersten Teil dieser Serie habe ich neben einer allgemeinen Einführung auch ein formalles Vorgehen beschrieben. Heute stelle ich 2 informelle Vorgehen vor, die man nutzen kann, um spontane Reviews durchzuführen. Dabei handelt es sich um „Email Pass-Around“ und „Peer Review“.
Email Pass-Around:
Im Gegensatz zu dem formellen Vorgehen benötigt man beim „Email Pass-Around“-Verfahren keinen großen verwaltungstechnischen Aufwand, um das Review zu organisieren. Der Entwickler schickt einfach die Codeänderungen per Mail an alle Kollegen. Diesen Vorgang kann man mit einem Commit-Hook automatisieren. Vorteil bei diesem Vorgehen ist, dass jeder Entwickler, der an dem Projekt arbeitet, den Code anschauen und beurteilen kann. Das Ganze kann durchaus asynchron passieren, somit kann das Review zu einem passenden Zeitpunkt durchgeführt werden. Nachteil ist, das im „worst case“ niemand den Code anschaut. Hier muss unter den Entwicklern eine entsprechnde Disziplin herrschen. Auf der anderen Seite ist ein Entwickler normalerweise daran interessiert ein bestmögliches Produkt zu erstellen.
Peer Reviews:
Möchte man sicherstellen, dass Code Reviews durchgeführt werden, aber den Overhead eines formellen Vorgehens vermeiden, bietet sich ein Peer Review an. Hierbei besprechen 2 Entwickler eine Codepassage. Einer der Entwickler sollten den Code programmiert haben. Die Länge des Codes is in der Regel zwischen 100 und 300 Zeilen. Für diese Codemenge muss man ca. 1 Stunde einplanen. Wichtig ist, dass man nicht von einer Lehrer-Schüler Beziehung ausgeht, sondern sich beide Entwickler als gleichberechtigt verstehen. Problem bei Peer Reviews ist, dass diese nicht „von oben“ gesteuert werden können. Wenn man dies trotzdem versucht, wird ein solches Vorgehen schnell zu einem Muss und wird nur noch halbherzig duchgeführt, was dann weder die Verbreitung des Wissens beschleunigt, noch die Codequalität verbessert.
Fazit:
Aus persönlicher Erfahrung kann ich sagen, dass in einer angenehmen Atmosphäre Peer Reviews am meisten bringen und dabei auch noch Spaß machen. Bei uns hat sich eingebürgert die Peer Reviews in einem kleinen Konferenzraum durchzuführen. So können beide Entwickler auf einem Beamer oder großem Monitor den Code anschauen und bei der Diskussion fühlt sich auch kein Kollege gestört. Eine Tasse Kaffee gehört ebenfalls zu einem Review. Anmerkungen werden gleich in den Code als TODO geschrieben und zeitnah angegangen.
Email Pass-Around nutzen wir schon seit Jahren und dieses Verfahren funktioniert relativ gut und hat schon den ein oder anderen Patzer im Code aufgedeckt. Die Asynchronität ist hier ein sehr spannender Aspekt. Und wer seine Firmenmails aufs Handy bekommt, kann überall mal schauen, was am Code gearbeitet wird – sofern man denn will.