{"id":182,"date":"2015-05-18T21:02:22","date_gmt":"2015-05-18T19:02:22","guid":{"rendered":"http:\/\/invidit.de\/blog\/?p=182"},"modified":"2015-07-16T20:44:45","modified_gmt":"2015-07-16T18:44:45","slug":"1-1-3","status":"publish","type":"post","link":"https:\/\/invidit.de\/blog\/1-1-3\/","title":{"rendered":"1 + 1 = 3"},"content":{"rendered":"

Hallo Spa\u00df-Coder.<\/p>\n

Heute wollen wir uns mit dem Thema Pair Programming<\/strong> besch\u00e4ftigen. Wir werden zum einen die Frage beantworten, warum es uns so viel Spa\u00df macht und zum anderen ausf\u00fchren, warum es auch aus wirtschaftlicher Sicht sinnvoll ist, wenn man es mittel- bis langfristig betrachtet.<\/p>\n

 <\/p>\n

Zun\u00e4chst aber mal wieder ein paar Bilder zur Einstimmung. Woran denkt ihr, wenn ihr folgendes Bild seht – bezogen auf Softwareentwicklung und der Anforderung eine \u00c4nderung durchzuf\u00fchren:<\/p>\n

\"PlainRoad\"<\/a><\/p>\n

Wir haben eine saubere, asphaltierte Stra\u00dfe –> sauberen, gut strukturierten Code. Wir werden gut gef\u00fchrt durch Leitplanken und der Linie in der Mitte der Stra\u00dfe. Sicher, es ist eine kurvige Stra\u00dfe, aber wir f\u00fchlen uns recht sicher, diese ohne gr\u00f6\u00dfere Probleme meistern zu k\u00f6nnen.<\/p>\n

Mit welcher Art von Fahrzeug glaubt ihr, kommen wir hier schnell vorw\u00e4rts?<\/p>\n

Wie w\u00e4re es mit diesem hier?<\/p>\n

\"British<\/a>

British Grand Prix 2014, Formula 1 Practice Session 1<\/p><\/div>\n

Wir haben glatte Stra\u00dfen, k\u00f6nnen den Weg gut erkennen und m\u00fcssen uns nicht gro\u00df anstrengen. Hier kommen wir sehr gut und schnell alleine und mit einem Fahrzeug aus, dass f\u00fcr diese Art der Stra\u00dfe optimiert ist.<\/p>\n

 <\/p>\n

In der Realit\u00e4t finden wir Code dieser Art leider viel zu selten. Die Herausforderung, die wir uns bei einer neuen Anforderung an unserem Code stellen m\u00fcssen, haben eher den Charakter des folgenden Bilds:<\/p>\n

\"RockyRoad\"<\/a><\/p>\n

Ein Weg l\u00e4sst sich erahnen, dieser ist aber schmal und steinig. Es geht bergauf und bergab. Nur einen Meter zu weit zur Seite abgewichen und schon werden wir abst\u00fcrzen. Haben wir nun kein Sicherungsseil (nennen wir es mal „automatisierte Tests“), wird dies mit Sicherheit keinen guten Ausgang finden.<\/p>\n

Wie weit kommen wir hier mit unserem oben abgebildeten Fahrzeug? Genau, nicht sehr weit. Das liegt zum einen nat\u00fcrlich an der geringen Bodenfreiheit, die uns auf dem unwegsamen Gel\u00e4nde eher hinderlich ist. Was aber w\u00fcrde uns hier helfen?<\/p>\n

\"OLYMPUS<\/a>

Liqui Molly Rally 2<\/p><\/div>\n

Ihr habt sicher schon erraten, dass dies kommen wird. Aber warum? Was genau unterscheidet das Fahren eines Rall-Autos vom Fahren eines Formel 1 Boliden? Sicherlich fallen die offensichtlichen Unterschiede auf: die h\u00f6here Bodenfreiheit, das Reifenprofil, die Windschutzscheibe, die vor dem aufspritzenden Schlamm sch\u00fctzt. Aber schauen wir mal genauer hin:<\/p>\n

\"RallyBinoculars\"<\/a><\/p>\n

Ein Blick ins Cockpit zeigt uns, dass hier nicht nur ein Fahrer im Wagen sitzt und ihn \u00fcber das schwere Terrain steuert, sondern zwei. Der eine f\u00e4hrt das Auto und h\u00e4lt es auf Kurs. Dabei konzentriert er sich auf die Strecke, die er unmittelbar vor Augen hat. Der andere sitzt daneben und schaut auf eine Karte. Er gibt dem Fahrer Anweisungen dazu, was als n\u00e4chstes auf ihn zukommt, damit dieser sich darauf vorbereiten kann.<\/p>\n

 <\/p>\n

Was ist Pair Programming?<\/h2>\n

Auch beim Pair Programming sitzen wir zu zweit vor dem Rechner, in der Regel um ein Feature zu entwickeln. Einer der Partner sitzt dabei an der Tastatur und schreibt, der andere sitzt daneben und schaut zu. Die Rollen entsprechen dabei genau den gleichen, wie beim Fahren eines Rally-Autos. Man nennt die beiden Rollen:<\/p>\n

Driver<\/span> <\/span><\/strong>und Navigator<\/strong><\/span><\/p>\n

Der Driver<\/strong> ist derjenige, der an der Tastatur sitzt und den Code schreibt. Er h\u00e4lt den gerade zu entwickelnden Code im Auge und konzentriert sich darauf, den n\u00e4chsten Schritt umzusetzen. Der Navigator<\/strong> kann sich derweil schon mit dem n\u00e4chsten Schritt besch\u00e4ftigen oder den aktuellen Schritt noch einmal hinterfragen und auf Sinnhaftigkeit \u00fcberpr\u00fcfen.<\/p>\n

Beim Pair Programming ist es aber noch wichtig, dass die beiden Rollen regelm\u00e4\u00dfig wechseln. Was sich beim Rallyfahren eher schlecht umsetzen l\u00e4sst, ist beim Pair Programming eines der wichtigsten Regeln. Durch das Wechseln der Rollen hat jeder mal einen anderen Blick auf den Code und besch\u00e4ftigt sich gedanklich auf anderen Ebenen. Das verbessert das Gesamtverst\u00e4ndnis f\u00fcr den Code und das umzusetzende Feature. Auch erh\u00f6ht sich durch den Wechsel der Grad des Wissensaustauschs.<\/p>\n

 <\/p>\n

Warum Pair Programming?<\/h2>\n

Die Aufgaben teilen sich also auf in kurzfristige und mittelfristige Umsetzung. Ihr kennt das sicher, dass ihr, wenn ihr alleine Code schreibt am Ende eines logischen Blocks ankommt und euch fragt, ob das nun wirklich der richtige oder beste Weg der Implementierung war. Falls nicht, fangt ihr in diesem Fall noch einmal von vorne an. Ein Navigator h\u00e4tte euch darauf bereits vorher hinweisen k\u00f6nnen und somit Zeit und M\u00fche gespart. Sind wir alleine unterwegs, k\u00f6nnen wir uns entweder auf die kurzfristige, oder auf die mittelfristige L\u00f6sung konzentrieren. Beides gleichzeitig ist nicht in gleicher Qualit\u00e4t m\u00f6glich.<\/p>\n

Es gibt aber noch weitere Gr\u00fcnde, die daf\u00fcr sprechen, Code nicht alleine, sondern in einem P\u00e4rchen zu entwickeln:<\/p>\n

Weniger Fehler<\/strong>
\nPair Programming f\u00fchrt zu weniger Fehlern und somit zu weniger Aufwand bei der Fehleranalyse und Suche. Je fr\u00fcher ein Fehler im Entwicklungsprozess gefunden wird, desto g\u00fcnstiger ist die Behebung. Ein guter Navigator, der einen Fehler bereits bei der Beobachtung des Drivers entdeckt sorgt also f\u00fcr die g\u00fcnstigste aller m\u00f6glichen Fehlerbehebungen.<\/p>\n

H\u00f6here Disziplin<\/strong>
\nPaare entwickeln viel eher an der richtigen Stelle und machen k\u00fcrzere Pausen. Arbeiten wir in Paaren zusammen, lassen wir uns weniger ablenken, etwa durch E-Mails oder Kollegen. Auch ist die Hemmschwelle anderer Kollegen h\u00f6her, ein Paar zu st\u00f6ren, als einen einzelnen Entwickler.<\/p>\n

Besserer Code<\/strong>
\nBeim Pair Programming entwickelt man sich weniger leicht in Sackgassen und erreicht so eine h\u00f6here Qualit\u00e4t. Auch werden Konventionen meist sofort eingehalten und bessere Namen gefunden. Auch die Struktur des Codes ist meist leichter verst\u00e4ndlich und nachvollziehbarer als bei einem einzelnen Entwickler.<\/p>\n

Freude an der Arbeit<\/strong>
\nPair Programming macht Spa\u00df! Es ist oft spannender und interessanter als alleine zu arbeiten. Auch hilft es dabei, den einzelnen vor \u00dcberforderungen zu sch\u00fctzen. Wenn einer nicht weiter wei\u00df, hat der andere vielleicht eine Idee. Haben beide keine, l\u00e4sst sich zu zweit schneller ein m\u00f6glicher L\u00f6sungsansatz entwickeln als allein. Auch ist die Hemmschwelle geringer nach Hilfe zu fragen. Man hat sich ja bereits eingestanden, dass man feststeckt, was meist der Hauptgrund daf\u00fcr ist nicht nach Hilfe zu fragen, der eigene Stolz.<\/p>\n

Wissensvermittlung<\/strong>
\nJeder hat Wissen, das andere nicht haben. Pair Programming ist eine M\u00f6glichkeit, dieses Wissen zu teilen. Wenn das gesamte Team Pair Programming betreibt und die jeweiligen Partner oft wechseln, erlangen alle Wissen \u00fcber die gesamte Codebasis. Dies wiederum f\u00fchrt zu einem geringeren Projektrisiko hinsichtlich Mitarbeiterfluktuation und Mitarbeiterabwesenheiten. Es verringert somit den Bus-Faktor<\/a>.<\/p>\n

Teambildung<\/strong>
\nDurch Pair Programming lernen sich Entwickler gegenseitig schneller kennen. Auch steigt der gegenseitige Respekt, wodurch die Zusammenarbeit verbessert werden kann.<\/p>\n

Was spricht gegen Pair Programming?<\/h2>\n

Kosten<\/strong>
\nPair Programming f\u00fchrt zu einer geringeren Geschwindigkeit bei der Programmierung. Das ist naheliegend, da ja nun nicht mehr nur einer, sondern zwei Entwickler mit dem gleichen Feature besch\u00e4ftigt sind. Aber wie hoch glaubt ihr, ist der Aufwand eines gut funktionierenden Paars? Doppelt so hoch, weil es zwei Entwickler sind? 150%, weil sie eher die richtige L\u00f6sung finden? 100%, weil sie nun doppelt so schnell sind, da sie nicht mehr abgelenkt werden?<\/p>\n

\u00dcblicherweise geht man davon aus, dass ein Paar f\u00fcr ein Feature etwa 115% der Zeit braucht, also pro Entwickler etwa eine um 7,5% geringere Produktivit\u00e4t gegen\u00fcber einem einzelnen Programmierer hat. Da die Vorteile wie etwa bessere Qualit\u00e4t und ordentlicher und lesbarer Code bereits w\u00e4hrend der Entwicklung zum Tragen kommen, werden die Kosten hierbei sogar noch geringer ausfallen (was aber nur schwer messbar ist). Schauen wir uns die langfristigen Vorteile wie etwa den Wissensaustausch oder die weichen Faktoren, wie Spa\u00df an der Arbeit an, sind die Kosten sicherlich gut investiert.<\/p>\n

Teamfindung<\/strong>
\nPair Programming ist zu Beginn – je nach eigener Pers\u00f6nlichkeit – ggf. ein wenig schwierig. Seid ihr der Driver, schaut euch nun st\u00e4ndig jemand \u00fcber die Schulter und sagt euch, was ihr „falsch“ macht. Seid ihr der Navigator, m\u00fcsst ihr euch darauf konzentrieren, den Code des Drivers zu lesen, zu verstehen und in den Kontext des Features zu bringen. Passt der Code zu dem was ihr im Team erreichen wollt? Sind die Namen gut gew\u00e4hlt? Ist der Code ordentlich strukturiert? Falls nicht, m\u00fcsst ihr es ansprechen.<\/p>\n

Diese Offenheit f\u00fcr Feedback – geben und nehmen – ist nicht jedem gegeben und muss ge\u00fcbt werden. Das kostet neben \u00dcberwindung auch Zeit und Kraft. Auch eignen sich nicht alle Paare f\u00fcr Pair Programming. Kommt ihr mit einem Partner auch nach mehrmaligem Versuchen und der Kenntnis der Regeln zu der Erkenntnis, dass ihr nicht gut zusammen arbeiten k\u00f6nnt, muss auch dies offen angesprochen werden.<\/p>\n

Unterschiedliche Programmierstile<\/strong>
\nWichtig f\u00fcr gut funktionierendes Pair Programming ist ein einheitlicher Programmierstil. Es ist hilfreich sich im Team auf ein paar grundlegende Regeln zu einigen. Wo stehen Variablendeklarationen? Wie sollen Klassen benannt werden? Wie formatieren wir den Code? Es ist wenig hilfreich, sich im Pair \u00fcber solche Themen zu unterhalten, das h\u00e4lt auf und verringert die Produktivit\u00e4t. Wurde sich einmal auf eine Konvention geeinigt, sorgen beide daf\u00fcr, dass sie eingehalten werden.<\/p>\n

Urheberrecht und Haftung<\/strong>
\nWer hat das Recht am Code, wenn er nicht nur von einem geschrieben wird? Wer haftet f\u00fcr fehlerhaften oder urheberrechtsverletzenden Code? Entwickelt ihr Code im Paar f\u00fcr euer Unternehmen, stellen sich diese Fragen sicher nicht, in beiden F\u00e4llen tritt das Unternehmen ein. Aber was ist mit Code, der unternehmens\u00fcbergreifend\u00a0 erstellt wird? Oder Code, den ihr privat im Paar entwickelt? Diese Fragen lassen sich deutlich schwerer beantworten, als wenn der Code nur von einem Entwickler geschrieben wurde.<\/p>\n

 <\/p>\n

Wie kann man Pair Programming durchf\u00fchren?<\/h2>\n

Im Grunde ist es recht einfach. Setzt euch zu zweit vor den Rechner. Einer an der Tastatur (der Driver) und einer daneben (der Navigator). Sorgt daf\u00fcr, dass beide einen guten Blick auf den Bildschirm haben (bei zwei Monitoren bietet es sich ggf. an, den Bildschirm zu spiegeln). Besprecht, auf welchem Weg ihr die Problemstellung angehen wollt und sagt immer, was ihr als n\u00e4chstes zu tun gedenkt. Der Navigator unterbreitet dauernd Vorschl\u00e4ge zur Verbesserung des Codes und \u00fcberlegt sich das weitere Vorgehen. Der Driver konzentriert sich auf die effektive Umsetzung der Ideen in Code.<\/p>\n

Wechselt regelm\u00e4\u00dfig die Rollen um den Blickwinkel auf die Problemstellung zu \u00e4ndern. Auch ist es hilfreich, bei bestimmten Themenschwerpunkten zu wechseln, je nachdem, wie gut der jeweils andere ist und ob der Fokus auf schnellen Erfolgen oder dem Austausch von Wissen liegt.<\/p>\n

Haltet euch nicht mit Feedback zur\u00fcck, tauscht euch \u00fcber alle Aspekte aus, jeder von euch kann vom anderen lernen! Es beginnt bei der Bedienung der IDE \u00fcber bestimmte Coding Patterns bis hin zur Entwicklung von ausgefeilten Algorithmen. Seid offen f\u00fcr Neues und f\u00fchlt euch nicht auf den Schlips getreten, wenn ihr einen Verbesserungsvorschlag erhaltet.<\/p>\n

Beim Pair Programming kann man ausgehend vom Wissensstand der Partner von folgenden Zusammenstellungen ausgehen:<\/p>\n

Experte – Experte<\/strong><\/p>\n

Dies ist offensichtlich die beste Kombination im Hinblick auf das zu erwartende Ergebnis und die Entwicklungsgeschwindigkeit. Liegt der Schwerpunkt der beiden Experten allerdings zu nah beieinander, besteht die Gefahr, dass die L\u00f6sung sich auf diesen Schwerpunktbereich konzentriert. Frei nach dem\u00a0Indonesischen Sprichwort\u00a0Wer nur einen Hammer hat, f\u00fcr den sieht jedes Problem wie ein Nagel aus.<\/em> Offenheit und konstruktiver Problemumgang hilft hier aber auch den Experten, kreative L\u00f6sungen zu finden.<\/p>\n

Experte – Anf\u00e4nger<\/strong><\/p>\n

Bei dieser Kombination spricht man auch oft vom Coaching. Der Experte gibt sein Wissen an den Anf\u00e4nger weiter. Dabei muss der Anf\u00e4nger kein kompletter Neuling auf dem Gebiet der Programmierung sein. Vielleicht ist er nur neu im Projekt oder kennt die Programmiersprache oder Entwicklungsumgebung noch nicht. Damit der Lerneffekt hoch ist, bietet es sich an, wenn der Anf\u00e4nger die Rolle des Drivers \u00fcbernimmt. Aufgabe, die ich selbst erledige, bleiben besser haften, als wenn ich nur zuschaue.<\/p>\n

Anf\u00e4nger – Anf\u00e4nger<\/strong><\/p>\n

Was auf den ersten Blick wie eine sinnlose Kombination klingt, entpuppt sich auf den zweiten Blick als Chance. Es gibt ein Thema, mit dem sich im Unternehmen noch niemand besch\u00e4ftigt hat, was aber die Zukunft des Markts ist? Nun k\u00f6nnt ihr euch einen Experten von au\u00dfen holen (was bei bew\u00e4hrten Umfeldern sicherlich keine schlechte Idee ist), oder ihr setzt euch zu zweit hin und t\u00fcftelt gemeinsam an einer L\u00f6sung. Dabei ist dies effizienter, als wenn sich einer allein durch das Thema w\u00fchlen muss (siehe oben, \u00dcberforderung).<\/p>\n

 <\/p>\n

Wichtig zu verstehen ist dabei, dass diese Kombinationen sich regelm\u00e4\u00dfig \u00e4ndern k\u00f6nnen. Teilweise sogar in einer einzigen Session! Einer der Partner hat noch nie was mit Lambda-Expressions gemacht, der andere schon? Experte – Anf\u00e4nger. Keiner der beiden kennt sich mit Linq aus? Anf\u00e4nger – Anf\u00e4nger. Beide wissen, wie sie ein Singleton Pattern implementieren? Experte – Experte. In jedem von uns steckt ein Experte – und ein Anf\u00e4nger. Wenn wir uns das bewusst machen, ist der Umgang damit im Paar deutlich einfacher.<\/p>\n

 <\/p>\n

Unsere Erfahrung mit Pair Programming<\/h2>\n

Wir arbeiten mittlerweile seit mehr als 10 Jahren im privaten Umfeld fast ausschlie\u00dflich im Pair Programming. Zun\u00e4chst war es aus der Not heraus geboren. Als wir mit unseren ersten Projekten anfingen hatten wir beide jeweils einen PC, keinen Laptop und von schnellem Internet f\u00fcr eine Online-Zusammenarbeit waren wir noch Jahre entfernt (erinnert ihr euch noch an 56k-Modems? Seht ihr…)<\/p>\n

Sp\u00e4ter kamen dann Zweit-PCs und Laptops hinzu, aber wir haben trotzdem weiterhin im Paar gearbeitet. Wir haben viel voneinander gelernt und das gemeinsame Entwickeln macht uns soviel Spa\u00df, dass wir einen Abend in der Woche und ab und zu am Wochenende genau das tun: im Paar Programmieren. Wir haben gemeinsam Aha-Erlebnisse, motivieren uns gegenseitig (was allerdings auch nicht immer funktioniert ;-)) und feiern kleine gemeinsame Erfolge.<\/p>\n

Wir sind davon \u00fcberzeugt, das Pair Programming die beste Art ist, Code zu schreiben.<\/p>\n

Wir w\u00fcnschen euch viel Spa\u00df beim Ausprobieren.<\/p>\n

Eure Spa\u00df-Coder<\/p>\n

P.S.: Hier noch eine (englischsprachige) Videoempfehlung zum Thema Pair Programming von der North Carolina State University<\/p>\n