Pair-Programming ist allgemein eine ziemlich doofe Zielsetzung. Klar mal für ein Problem, oder ein Experiment mit dem Kollegen am Rechner kuscheln ist ganz nett. Längere Sessions ermüden mich persönlich allerdings doch schnell und es schleicht sich dann auch bald ein Gefühl der Ineffizienz ein. Dabei lernt man gemeinsam neue Technologie kennen, teilt direkt das Wissen und steigert die Qualität des Produktes. Ganz nebenbei lernt man auch den Stil und die Denk- und Arbeitsweise der Kollegen kennen. Gerade letztere können aber stark von der eigenen abweichen und damit sind Konflikte eigentlich vorprogrammiert.
Ich persönlich bin also eher nicht der Pair-Programming Typ. Die oben genannten Vorteile finde ich persönlich in einem eigentlich stärker qualitätsorientieren Verfahren wieder, dem: Code-Review.
Leider kannte ich Code-Reviews bis vor einiger Zeit Code-Reviews primär als zufälliges Ereignis, bei dem dann typischerweise ein Verriss des untersuchten Codes stattfand. Grund für diese Reviews war meist, ein beim Testen aufgetretener Fehler, der einen anderen Entwickler auf den Plan rief. Ergo war das Review unbeliebt und unproduktiv.
Die zweite Variante die ich kannte war das öffentliche Code Review mit Beamer und großem Auditorium. Dabei wurden dann meist komplexe Codes an die Wand geworfen und spätestens nach 10 Minuten wich die Stimme des Präsentierenden dem angenehmen Rauschen des Beamers, das irgendwann wiederum durch ein: “noch Fragen” jäh unterbrochen wurde.
Die Wirklich geile Version des Code-Reviews aber ist die, welche stetig durchgeführt wird. Stetig weil sie Teil einer Definition of Done ist und weil jede Codeänderung, egal ob Bugfix oder Feature, von mindestens einem zweiten Entwickler begutachtet wird.
Wie schon erwähnt funktioniert das nur in einer Umgebung die konstruktiv und objektiv zu arbeiten bereit ist. Nicht jeder Entwickler hat die gleichen Ansprüche und Voraussetzungen, daher muss beim Review klar sein, dass der Code des anderen durchaus in Ordnung sein kann auch wenn man ihn selbst so niemals geschrieben hätte.
Allgemein habe ich Code-Reviews in meinen letzten Projekten als sehr hilfreich erfahren und lieben gelernt. Zum einen lernt man so den Stil- und die Lösungsstrategien der Kollegen kennen, zum anderen lernt man neuen heißen Scheiß kennen. Auf jeden Fall hat man am Ende immer das Gefühl als Team ein besseres Ergebnis geliefert zu haben.
Klar fasst man sich manchmal dabei an den Kopf, wenn man merkt was man da für einen Schmarn geschrieben hat, oder wie umständlich der andere gedacht hat, diese Minuten des WTF-Gemurmels werden aber meines Erachtens durch Lerneffekt und Qualitätsgewinn mehr als aufgewogen.
Ein Allheilmittel ist das Code-Review natürlich nicht. Vor allem zu komplexe und umfangreiche Änderungen sind schlecht für Reviews geeignet, sind aber dann auch Anzeichen für andere Probleme im Entwicklungsprozess.