Pair Programming

Als Software-Entwickler ist es wichtig, sich stetig neues Wissen anzueignen und dazuzulernen, um nicht den Anschluss zu verlieren. Für diese Wissensbeschaffung gibt es unterschiedliche Quellen. Ich nutze zum Beispiel „Tiny Tiny RSS“ zur Verwaltung meiner RSS-Feeds, in die ich täglich reinschaue und wo ich bekannte Blogs für Programmierung und Software-Entwicklung abonniert habe.

Eine andere Form, die seit neuem in meinem Betrieb zum Ausprobieren für die Auszubildenden eingesetzt wird, ist das Pair Programming, oder auf Deutsch die Paarprogrammierung. Wie der Name schon sagt, wird hier also nicht alleine, sondern zu zweit Code geschrieben. Der Ansatz dieser Arbeitstechnik stammt aus dem Entwicklungsmodell „Extreme Programming“.

Regeln

Wichtig dabei ist zu beachten, dass es Regeln gibt, die man beachten sollte:

• Beide Programmierer sind für den geschriebenen Code gleichermaßen verantwortlich.
• Beide Programmierer sind gleichgestellt und es darf keine Lehrer-Schüler-Beziehung geben.
• Während der eine den Code schreibt, sollte der andere aufmerksam sein und mögliche Fehler identifizieren. Zu zweit findet man Fehler deutlich schneller.
• Auch sollten diese Rollen nicht fest sein. Nach bestimmten Zeitintervallen sollten Tastatur und Maus gewechselt werden. Wie lange genau ein Intervall dauern sollte, kann man pauschal schlecht festlegen, da es auch von der Gesamtdauer des Pair Programmings abhängt, aber es sollte nicht allzu lange sein. Persönlich habe ich gute Erfahrungen damit gemacht, nach ungefähr 10 bis 15 Minuten zu wechseln.
• Vor allem derjenige, der den Code schreibt, muss kritikfähig sein und es muss darüber diskutiert werden können, wenn es Meinungsverschiedenheiten zur Problemlösung gibt.

Pair Programming Stile

Es gibt natürlich die Möglichkeit, die Regelung, wann man sich abwechselt, an einer Stoppuhr festzumachen. Eine andere Technik, die ich selber bisher noch nicht ausgetestet habe, orientiert sich eher am Fortschritt des Programms.

Das sogenannte „Ping-Pong“ Pair Programming gibt es in zwei verschiedenen Varianten, welche sich nach dem TDD-Prinzip (Test-Driven Development) verhalten. Bei der ersten der beiden Varianten gibt es eine Person, die den Test schreibt („Test Redder“) und die andere Person schreibt den Code, sodass der Test erfolgreich ausgeführt werden kann („Test Greener“). Dieses Vorgehen eignet sich bei einem Paar, bei dem einer von beiden noch nicht wirklich geübt darin ist, Tests zu schreiben. Durch das Zuschauen beim gemeinsamen Schreiben der Tests kann derjenige dazulernen, dass es auch möglich sein kann, die andere Form auszutesten.

Hierbei schreibt der erste von beiden einen Test, dann wird gewechselt, der zweite schreibt den Code, der den Test erfolgreich ausführbar macht. Ist der Test grün, bleibt die Tastatur noch bei Person 2. Diese schreibt den nächsten Test und erst dann wird wieder zu der ersten Person gewechselt. Diese macht dann zuerst wieder den Test grün und schreibt dann den nächsten Test.

Vorteile

• Durch das gemeinsame Programmieren lernt man automatisch voneinander, da sich einer von beiden in bestimmten Gebieten ein klein wenig besser auskennt. Das können ganz unterschiedliche Dinge sein:
  • Shortcuts zum schnelleren Arbeiten
  • Nutzung eines Frameworks anstatt selber zu programmieren
  • Höhere Wissensbasis in der spezifischen Domäne
• Die Entwicklungskosten sind geringer. Im ersten Moment mag das widersprüchlich sein, aber die Entwicklungszeit alleine ist laut Studien nur 15% höher statt doppelt so hoch im Vergleich zum alleinigen programmieren. Das liegt an der gesteigerten Aufmerksamkeit beim Coden, da man immer von einem Augenpaar beachtet wird.
• Automatisch steigert sich dadurch auch die Qualität des Codes, da man zu zweit programmiert und sich so gegenseitig dazu motiviert, den Code besser zu strukturieren und verständlicher zu machen.
• Das führt auch dazu, dass Fehler viel schneller gefunden werden können, wenn man zu zweit sucht oder der eine schon einen Fehler finden kann, während der andere grade noch am Schreiben ist.

Best Practices

Natürlich ist es immer wichtig, dass die Kommunikation zwischen dem Schreibenden und Beobachtenden aufrechterhalten wird. Ansonsten ist das Risiko groß, dass es schnell dazu kommt, dass beim Beobachtenden das Interesse verschwindet und dieser abgelenkt wird. Verhindert werden kann dies auch durch kürzere Zyklen und somit kürzere Pausen zwischen den Wechseln.

Auch sollte darauf geachtet werden, nach einer bestimmten Zeit gemeinsame Pausen einzulegen, damit der Beobachtende nicht anfängt, dazu zu neigen, seine Zeit als Pause zu betrachten. Es muss verstanden werden, dass beide Rollen gleichwertig sind. Wird darauf nicht Wert gelegt, wird quasi die Grundregel missachtet und alle oben genannten Vorteile gehen verloren.

Sind an dem Platz zwei Monitore vorhanden, sollte die Arbeit für das Pair Programming aber größtenteils auf einen Bildschirm begrenzt werden, vor dem die beiden Teilnehmer nebeneinander und möglichst gleich weit entfernt sitzen. Der Beobachtende sollte sich nicht hinter dem Schreibenden “verstecken” und braucht eine ebenso gute Sicht auf den Monitor.

Weiterhin sollten beide Teilnehmer des Pair Programmings in der Lage sein, die vorhandene Peripherie problemlos bedienen zu können. Dies kommt insbesondere dann zum Tragen, wenn an dem Arbeitsplatz eine ergonomische Maus oder Tastatur benutzt wird und einer von beiden diese im normalen Arbeitsalltag nicht benutzt. Es mag dann durchaus sinnvoll sein, an einem anderen Platz zu arbeiten oder diese Geräte vorübergehend auszutauschen.

Fazit

Insgesamt bietet das Pair Programming eine Vielzahl an Vorteilen, die dem Team auch langfristig helfen. Der Code wird besser, er wird weniger fehleranfällig und vor allem wird er insgesamt schneller fertig, wodurch Kosten gespart werden können.

Zwar konnte ich persönlich diese Technik noch nicht sehr lange ausprobieren, aber bisher hat es mir sehr gut gefallen und ich habe auch schon wahrgenommen, dass das Programmieren im Paar die genannten positiven Auswirkungen hat beziehungsweise haben kann.