Was unterscheidet Pair-Programming davon, zu zweit vor einem Rechner zu sitzen?
Aus meiner Sicht 3 Dinge:
- Klare Rollendefinition
- Ein festes Prozedere
- Eine (mentale) Checkliste
Die Rollen
Die beiden Rollen, die wahrgenommen werden müssen sind die des Fahrers und die des Navigators. Dabei ist die Aufteilung ähnlich wie im Motorsport - der Fahrer ist dafür zuständig, bis zur nächsten Kurve zu kommen und der Navigator dafür, dass das Team auch nach der Kurve noch weiss, wie es weiter geht.
Übertragen auf die Programmierung bedeutet das, dass der Fahrer sich sowohl um Maus und Tastatur (entsprechend Gas und Kupplung) als auch um die konkreten Details der näheren Umgebung wie Klassen, Syntax, Struktur des aktuellen Codeblocks (entsprechend Geschwindigkeit, Drehzahl Straßenzustand etc.) kümmert. Der Navigator kümmert sich so lange um die weiter entfernten Zielen wie Design, Schnittstellen, Frameworks und Architektur (entsprechend Strassenkarte, Himmelsrichtung, Entfernungen etc.).
In dieser Rolle ist es auch Aufgabe des Navigators sich um so etwas wie das Roadbook – im Falle der Programmierung um den GoalStack – zu kümmern sowohl um die Erstellung, als auch um die Abarbeitung!
Das feste Prozedere
Das Prozedere zum Pair-Programming umfasst einen Bildschirm, eine Tastatur und eine Maus sowie eine Stoppuhr (welcher Art auch immer). Die Maßgabe lautet nun, dass beide Entwickler zugleich vor der Maschine sitzen, sich vor Beginn der Arbeit über das Ziel und den Zeitrahmen absprechen und in festen Intervallen von 10 bis 15 Minuten die Rollen wechseln. Beim Rollenwechsel sollten dabei tatsächlich nur Maus und Tastatur verschoben werden und weder die Sitzpositionen, noch die Monitorposition angepasst werden. Letzteres soll sicher stellen, dass der Navigator tatsächlich den gleichen Zugang zum Code hat wie der Fahrer. (Anm: Tools wie Key Jedi helfen zusätzlich, falls der Fahrer ein Mausgegner sein sollte...)
Die Checkliste
Die Checkliste für den Navigator kann entweder sogar physisch vorliegen, sollte aber auf jeden Fall zumindest mental bei jeder Zeile durchgegangen werden, die der Fahrer programmiert.
Kommt es zu "Verstößen" gegen die Checkliste ist es Aufgabe des Navigators, zu entscheiden, ob dieser "Verstoß" sofort aufgelöst werden muss (was zum Beispiel im Falle von Rechtschreibfehlern sicherlich sinnvoll ist) oder ob diese Verstöße eher in den GoalStack gehören – also auf eine kurze, völlig informelle Liste von Dingen, die man "noch in dieser Session" bereinigen muss. In diese letzte Kategorie fallen insbesondere notwendige Refactorings und Verstöße gegen das DRY oder YAGNI Prinzip.
Ein guter Startpunkt für eine solche Checkliste ist aus meiner Sicht die folgende:
- [Nur bei TDD und BDD] Haben wir einen (fehlschlagenden) Test für den Code, den wir gerade schreiben wollen?
- Wird die gleiche Absicht an andere Stelle im Code bereits ausgedrückt? (Verstoß gegen das Don't Repeat Yourself Prinzip, DRY)
- Benötigen wir diesen Code zu diesem Zeitpunkt? (Verstoß gegen das You Aren#t gonna Need It Prinzip, YAGNI)
- Kommuniziert der Code klar die Absicht, die mit ihm verfolgt wird? (Gegenbeispiel für C-Programmierer: {while(*p++=*q++)} )
- Entspricht der Code dem vereinbarten Coding-Style?
- Entspricht der Code den vereinbarten Naming Conventions?
- Entspricht der Code der vorgesehenen Nutzung des Frameworks?
- Ist der Code ausreichend dokumentiert?
- Bietet der Code Optionen für Refactorings? (Enthält er Code-Smells?)
Anm.:
Vor langer Zeit gab es mal einen guten aber kurzen Artikel darüber, was Pair-Programming davon unterscheidet einfach zu zweit vor einem Rechner zu sitzen. Leider hat selbst extensive Google und Twitter-Recherche keine greifbaren Hinweise auf diesen Artikel geliefert, was bei mir die Befürchtung aufkommen lässt, dass es sich bei diesem Artikel und einen echten gedruckten Artikel handelt - daher diese Zusammenfassung aus meiner Sicht.
Einige der Quellen, auf die ich mich dabei beziehe sind:
http://c2.com/cgi/wiki?PairProgrammingPattern
http://c2.com/cgi/wiki?GoalStack
http://c2.com/cgi/wiki?LetTheJuniorDrive
http://webpages.cs.luc.edu/~anh/170/Kindergarten.html
http://softwarecreation.org/2008/pair-programming-to-do-or-not-to-do/
