bytelude

Meinem Arbeitgeber ist Fortbildung und Wissenserweiterung/-auffrischung sehr wichtig. Und deshalb gab es vor einigen Wochen einen Workshop zum Thema Pair Programming, einer Teilmenge von XP, also dem Extreme Programming.

Die Thematik Pair Programming war mir schon länger geläufig, allerdings hatte ich zum Teil völlig falsche Vorstellungen davon und mir waren die Konzepte dahinter völlig fremd. Pair Programming ist eben nicht nur der Zustand, dass ein Programmierer am Rechner sitzt und ein zweiter ihm ständig über die Schulter schaut und kommentiert. Es geht viel mehr darum, dass der Code wirklich gemeinschaftlich entsteht und vor allem nicht ein Entwickler arbeitet und der Partner sich langweilt.

Grundlagen

Die Idee des Pair Programmings basiert auf dem Driver-Navigator Prinzip, welches man aus dem Rally Sport kennt. Der Fahrer ist vom Beifahrer abhängig, der Beifahrer wiederrum vom Fahrer. Und: dadurch, dass beide zusammen arbeiten, sind sie effizienter. Der Fahrer kann sich voll und ganz auf die aktuelle Situation einstellen und seine komplette Energie in die optimalste, derzeit angebrachte Fahrweise stecken. Der Beifahrer hingegen hat den Überblick über das große Ganze. Er kennt die ganze Strecke in- und auswendig. Da er sich nicht primär um die aktuelle Situation kümmern muss, kann er ruhig Ansagen für kommende Ereignisse machen.

Das gleiche Prinzip kommt im Pair Programming zum Einsatz: der Programmierer an Tastatur und Maus ist der Driver, der Programmierer neben ihm der Navigator. Der “Driver” kümmert sich um die aktuelle Problematik, der “Navigator” behält die Überblick über die komplette oder aber zumindest die übergeordnete Problematik. Außerdem führt er nicht den gleichen Gedankengang wie der Driver aus, was ihm ermöglicht, evtl. Fehler eher zu erkennen oder auf kommende Fehler hinzuweisen.

Die 7 Säulen des Pair Programmings

Man kann die Grundsätze des Pair Programmings auf 7 Säulen aufteilen. Die Säulen verdeutlichen, welche Vorteile Pair Programming gegenüber anderen Konzepten hat:

pair pressure – sich gegenseitig fokussieren und andere wegschicken bzw. Ablenkungen aus der Welt schaffen.

pair negotiation – das gegenseitige Sparring bzw. die gegenseitige Verbesserung durch ständiges direktes Feedback.

pair courage – den Mut, Dinge und vor allem Code zu ändern. Stichwort Refactoring.

pair review – Das ständige Reviewen des Codes.

pair debugging – Vier Augen sehen mehr als zwei – vor allem beim Debugging!

pair learning – das voneinander Lernen und der somit entstehende Wissenstransfer.

pair trust – das Vertrauen zum partner und auch in seine Methoden.

Wissensstufen

Ein wichtiger Aspekt des Pairings ist die Zusammenstellung des Paares. Diese ist abhängig von den verfügbaren Programmierern (und ihren Charaktereigenschaften), aber auch von der zu lösenden Aufgabe. Man kann den Erfahrungsgrad hierzu in 3 Gruppen, die sich aus dem Japanischen Kampfsport ableiten, unterteilen:

Shu, Ha und Ri

Wenn man die 3 Worte bzw. Silben von vorn nach hinten liest, hat man schon die Klassifizierung. Wichtig hierbei ist: JEDER Programmierer wechselt im Laufe seiner Karriere zwischen diesen Gruppen immer wieder hin und her.

Die “Shu” sind Einsteiger bzw. Juniors. Hierbei geht es nicht unbedingt nur um die allgemeinen Programmierskills – auch wenn ein “Ha” oder “Ri” eine komplett neue Sprache oder ein neues Framework kennen lernt, dann ist er zunächst wieder ein “Shu”.

Die nächste Stufe, “Ha” genannt, umschreibt den Zustand, dass man sich mittlerweile schon gut zurecht findet, die neue Sprache oder das Framework oder was auch immer bereits sehr gut beherrscht und die ersten Regeln in Frage stellt. In diesem Stadium baut man stark an Wissen auf.

Wenn man die Stufe “Ri” erreicht hat – und dafür braucht man mindestens ca. 10.000 Stunden Arbeit im jeweiligen Themengebiet – dann ist man an der Spitze angekommen. Auf diesem Level gelten so gut wie keine direkten Regeln mehr – denn diese sind bereits in das Unterbewusstsein übergegangen. Für zu bewältigende Aufgaben findet man so gut wie immer die eleganteste Lösung – nicht zwangsweise auf Basis von Patterns – sondern wirklich die optimale Lösung. Daher: Losgelöst von den Regeln, aber indirekt doch basierend auf ihnen.

Paar-Kombinationen

Nachdem nun die Grundlagen soweit verstanden sind, kommt es zur Anwendung. Ein wichtiger Faktor des Pair Programmings ist die Kombination der Partner – basierend auf ihrer Klassifizierung.

In der Regel sollte man darauf achten, dass zwischen den Partnern eine Wissens-Stufe liegt – das hat den Effekt, dass der Entwickler mit dem geringeren Wissensstand besser Wissen aufbauen kann. Für den Partner in der höheren Klasse dient diese Konstellation als weitere Festigung des Wissens.

Sollte man an eine wirklich brenzlige Stelle mit großem Impact für das Projekt oder die Firma kommen, kann man auch auf die Kombination “Ri” – “Ri” setzen. Diese wird aller Wahrscheinlichkeit nach zu einer sinnvollen und schnellen Lösung des Problems führen, jedoch sollte hier beachtet werden, dass Leute dieses Kaliebers nicht zu lange im Paar arbeiten. Gurus arbeiten im Allgemeinen auch eher allein 😉

Sprünge über 2 Klassen, also die Kombination “Shu” – “Ri”, machen nur selten Sinn. Der Unterschied ist sehr enorm und es besteht die Gefahr, dass der “Shu” den “Ha” Level mehr oder weniger überspringen und sich direkt über bestimmte Grenzen hinweg setzen möchte. Für kürzere Zeiträume kann man diese Kombination allerdings für die komprimierte Wissensweitergabe verwenden.

Sind alle 3 Klassen in einem Team vertreten, so kann evtl. auch ein “Shu” – “Shu” Paar Sinn machen. Der Wissenstransfer ist sicher nicht so hoch wie in anderen Konstellationen, allerdings lernt es sich zusammen immerhin leichter als allein und diese Kombination führt dazu, dass man die Nerven der erfahreneren Entwickler schonen kann.

Feedbackschleifen

Ein wichtiges Element in der Entwicklung sind sogn. Feedbackschleifen – also die Zeit, in der ein Entwickler mehr oder weniger das tut, was er für richtig hält, ohne dass es der Kunde oder jemand anderer sieht und beurteilt. Bleibt man im Feld der agilen Entwicklung, dann gibt es dort 2 Feedbackschleifen: Den Sprint (7-14 Tage) und das Daily Standup (1 Tag). Je kleiner die Feedbackschleife wird, desto weniger Fehlentwicklungen können auftreten, da schnell interveniert werden kann.

Wenn man nun ins Pair Programming einsteigt, dann kommt eine weitere Feedbackschleife hinzu, die jedoch im Minutenbereich liegt. Egal, was man gerade codet – der Partner sieht es und kann und wird es umgehend beurteilen sowie kommentieren. Diese extrem verkürzte Feedbackschleife vermindert sehr stark Fehlentwicklungen, zumindest auf Codeebene. Auch werden so sehr schnell Verständnisprobleme der Aufgabenstellung sichtbar.

Zusammenfassend kann man sagen: je mehr Feedback man bekommt, desto besser kann man sich entwickeln – je länger der Zeitraum bis zum nächsten Feedback ist, desto länger kann man auf dem falschen Weg unterwegs sein.

Vorgehensweise

Kommen wir abschließend zum eigentlichen Vorgehen – denn darum liest du diesen Artikel ja 😉

Um jegliche Ablenkung zu minimieren, setzen sich beide Entwickler an EINEN Rechner. Um die Zusammenarbeit zu optimieren, sollte man das System mit 2 Monitoren betreiben, die beide das gleiche anzeigen. So hat jeder Entwickler den bestmöglichen Blick auf das Geschehen. Wichtig hierbei ist: es gibt nur eine Maus und eine Tastatur, die zu einem Zeitpunkt bedient wird! Für einen einfacheren Wechsel zwischen den Rollen des Drivers und des Navigators kann man gern eine zweite Maus und eine zweite Tastatur anschließen.

Für unser Beispiel haben wir den Driver “Tom” und den Navigator “Paul”.

Der Driver Tom beginnt nun damit, einen Unit Test zu schreiben, der natürlich gleich brechen wird. Nun übernimmt Paul (er wird zum Driver) und schreibt die zu bearbeitende Funktion oder Klasse so, dass der Test nicht mehr bricht. Dies geschieht auf einem extrem simplen Niveau! Beispiel:

Test:

function testMethod() {
	assertTrue(method());
}

Der ausgeführte Test wird brechen, weil es die aufzurufende Methode noch gar nicht gibt – und wenn es sie doch geben sollte, dann ist sie leer und liefert keinen Rückgabewert.

Hier nun die zugehörige Funktion, die Paul darauf hin geschrieben hat:

function method() {
	return true;
}

Der Test läuft nun erfolgreich durch. In der nächsten Iteration wechseln beide wieder und Tom muss nun den Test so umbauen, dass er dem gewünschten Ergebnis wieder näher kommt. Er baut den Test so lange um, bis er wieder bricht. Dann wird wieder gewechselt und Paul muss dafür sorgen, dass seine “method” das vom Test gewünschte Ergebnis liefert.

Diese Vorgehensweise wird auch Test Driven Development genannt. Man macht sich erst Gedanken über den Test, der beweisen soll, dass die Funktion so läuft wie erwartet. Und erst anschließend wird die eigentliche Funktionalität implementiert.

Im Bezug auf das Pair Programming nennt man diese Vorgehensweise “ping pong pair programming”. Der Vorteil dieser Methode ist, dass man sich langsam an das Ziel herantastet. Jeder Entwickler kennt den Zustand, in dem man eine Implementierung gleich im ersten Zug baut, sich völlig verzettelt und von vorn beginnen muss. Genau diese Entwicklung soll an dieser Stelle verhindert werden. Man beschäftigt sich eben nicht mit dem großen ganzen, sondern tastet sich über kleine Iterationen immer näher an eine bessere Implementierung. Durch immer wieder einsetzendes Refactoring wird der Code somit immer weiter verbessert und optimiert.

Fazit
Ich möchte den Artikel an dieser Stelle erstmal beenden, weil im Prinzip auch schon alles gesagt ist. Die Hauptaufgabe, nach erlernen der Grundlagen, liegt nämlich in der Übung. Hierbei sollte man darauf achten, dass man den Partner ab und zu mal wechselt, um konstant neue Einflüsse auf die eigenen Skills zuzulassen.

Eine Problematik bleibt allerdings noch offen: wie verkaufe ich das meinen Kunden? Dabei handelt es sich in der Tat um einen der schwierigsten Aspekte. Man darf beim Pair Programming keinesfalls davon ausgehen, dass zwei Entwickler an einer Aufgabe auch doppelt so schnell entwickeln – wobei man diese Denkweise in der Programmierung allgemein unterbinden sollte, denn: 9 Frauen bringen ja auch nicht ein Baby in nur einem Monat zur Welt 🙂

Was man dem Kunden allerdings verkaufen kann, ist die effektivere Problemlösung und die bessere Verteilung von Wissen. Dies ist besonders interessant, wenn man mit Entwicklern des Kunden zusammen arbeitet. Ein weiteres, sehr wichtiges Argument, ist die bessere Code Qualität und geringere Bug-Anfälligkeit. Durch das ständige Code-Review können Flüchtigkeitsfehler stark vermindert werden, was für weniger Frust auf Seiten des Kunden als auch der Entwickler sorgt.

Abschließend sei gesagt: Probiert es aus! Pair Programming bringt euch als Entwickler deutlich weiter und es macht auch noch extrem Spaß.