**Dies ist eine alte Version des Dokuments!**
Pair Programming
Vorteile von Pair Programming
nach \cite[S. 319]{Goodliffe2006}
Wissenstransfer zwischen Entwicklern
zentriert den Fokus auf das Entwickeln (und vermeidet Tagträume)
erhöht die Disziplin
vermindert die Unterbrechungshäufigkeit (man stört zwei Personen, die arbeiten nicht so gerne, wie eine einzelne)
quasi "Echtzeit-Reviews" → besserer Code als Ergebnis
sozialer Faktor: die Entwickler lernen sich besser kennen und das fördert die Moral
Collective Code Ownership
verteilt gute Codepraktiken und -standards unter den Entwicklern
unterstreicht den Entwicklungsprozess
nach \cite[45:00]{Haines2009}
kontinuierliches Code-Review
man muss zwei Leute überzeugen, wenn man Schrott programmieren will
langweilige Aufgaben werden interessanter
schwierige Aufgaben werden leichter
weniger Fehler im Code
Code kann schneller in Produktion gehen
saubererer Code
zwei Leute "kennen" den Code → Truck Factor
Gründe gegen Pair Programming
nach \cite[50:00]{Haines2009}
"Das Management will kein Pair Programming!" → Das ist keine Ausrede! Wir als Entwickler sind verantwortlich für guten Code und müssen/dürfen entscheiden, wie dieser erstellt wird. Wir schreiben den Managern auch nicht vor, wie sie ihre Diagramme zeichnen sollen. Wer PP will, wird einen Weg finden, z.B. zwei Wochen lang ausprobieren und Management die Ergebnisse in Zahlen vorlegen, oder einfach den Job wechseln.