© Rasmus Ursem, 123RF

Teils aus Überzeugung, teils aus Verzweiflung bieten heute immer mehr Firmen Entwicklern eine Mitarbeit aus der Ferne an. Zugleich setzen agile Projektteams auf Pair Programming. Wie sich beide Trends technisch und wirtschaftlich unter einen Hut bringen lassen, erforscht der Artikel.

Seit agiles Projektmanagement in IT-Abteilungen Einzug gehalten hat, setzen Teams vermehrt auf Pair Programming (auf Deutsch “Paarprogrammierung”, [1]). Dabei arbeiten zwei Programmierer gleichzeitig an einem Computer. Der Knackpunkt ist, dass beide Personen eine eigene Tastatur und Maus verwenden. Idealerweise gehört auch jeweils ein eigener Monitor dazu.

Firmen, die sparen wollen und zwei Programmierer vor einen kleinen Laptop setzen, können sich die Paarprogrammierung auch schenken. Die Reibungsverluste sind bei dieser kuscheligen Light-Variante deutlich zu groß.

Beim Pair Programming gibt es klassischerweise einen Driver (die Person, die aktiv programmiert) und einen Navigator. Da beide Personen über eine eigene Tastatur verfügen, kann der Navigator jederzeit direkt in den Code einsteigen. Es kommt so zu jenen Ich-zeig-dir-das-gerade-mal-Momenten, in denen der Navigator dem Driver etwas demonstriert oder einfach einen Fehler korrigiert.

Ein Resultat dieser Arbeitsweise ist Code, der viel übersichtlicher ist und weniger Fehler enthält. Allerdings gibt es auch eine Schattenseite, denn Paarprogrammierung ist zugleich wesentlich anstrengender für beide Programmierer. Unternehmen können und sollen diese Arbeitsweise daher regelmäßig einsetzen, aber nicht jeden Tag von morgens bis abends. Außerdem ist es wichtig, dass die Chemie zwischen den beiden Entwicklern stimmt – nicht jeder Programmierer ergänzt jeden anderen problemlos!

Und jetzt remote

Das technische Setup (zwei Tastaturen, zwei Mäuse und idealerweise zwei Monitore) ist mittlerweile bei allen Betriebssystemen kein Problem mehr. Schwierig wird es allerdings, wenn noch ein zweiter Trend ins Spiel kommt: Remote Working (siehe Kasten “Remote Work in der Praxis”). Dabei arbeiten zwei oder mehr Personen gleichzeitig zusammen, sitzen aber nicht am selben Computer, weil sie sich an geografisch getrennten Orten befinden. Zum Glück sind Webcams und Headsets weit verbreitet, was es problemlos ermöglicht, kostengünstig miteinander zu kommunizieren. Über Screensharing lässt sich zudem der eigene Bildschirminhalt an den Gesprächspartner übertragen.

Allerdings ist dieses Setup weder Fisch noch Fleisch. Beim Pair Programming ist es wichtig, das beide Personen direkt ins Geschehen eingreifen können, nur so kommt es zur nötigen Dynamik. Andernfalls könnte sich die Firma den Aufwand auch einfach sparen und das fertige Programm zur Codereview einreichen.

Terminale Lösung

Freunde von Vim und Emacs dürfen sich jetzt freuen. Mit Tmate gibt es eine sehr einfache und gute Möglichkeit, über ein Terminal zwei remote arbeitende Personen miteinander zu verbinden. Die Installation erfolgt über den Paketmanager der Wahl (das Paket heißt fast immer »tmate«). Wer lieber den Quellcode selbst kompiliert, findet diesen auf der Projektseite [2].

Die Software ist ein Fork des Terminal-Multiplexers Tmux [3]. Die Person, die den zu bearbeitenden Sourcecode lokal verwaltet, startet dabei die Tmate-Session über die Eingabe des Befehls »tmate« in ein Terminal. Der ruft einen lokalen Tmate-Client sowie einen Tmate-Server auf, der wiederum eine SSH-Verbindung zum zentral gehosteten Tmate.io-Server etabliert (Abbildung 1).

Abbildung 1: Tmate basiert auf Tmux und erlaubt es zwei voneinander entfernt arbeitenden Entwicklern, über die Kommandozeile zu kooperieren.

Wer vorher noch nie SSH benutzt hat, muss mit »ssh-keygen« zunächst ein Schlüsselpaar generieren. Wer will, der kann auch einen eigenen Tmate-Server hosten und so die totale Kontrolle über die Kommunikation behalten.

Die Verbindung benutzt Gzip als Komprimierung, um die Bandbreite möglichst optimal auszunutzen. Auf dem zentral gehosteten Server meldet sich die zweite Person über einen normalen SSH-Client. Dort startet dann automatisch ein Tmate-Client, der sich mit dieser SSH-Session nutzen lässt. Bestechend an der Lösung ist, dass die zweite Person keine besondere Software installieren muss, sondern nur SSH benötigt. Den kompletten dafür notwendigen SSH-Befehl blendet Tmate kurz nach dem Start unten am Bildschirm ein (Abbildung 2).

Abbildung 2: Unten zeigt Tmate die SSH-Adresse für die Session.

In einer laufenden Tmate-Session arbeiten beide Programmierer gleichzeitig. Da sie sich ein Terminal teilen, lassen sich dort alle verfügbaren Editoren (etwa Vim und Emacs) ohne Einschränkungen verwenden. Nach Abschluss der Arbeiten lässt sich die Session auf beiden Seiten über »exit« beenden. Wer will, kann noch weitere Personen in die Session einladen. Wer mag, schränkt die Zugriffsrechte auf Read-only ein.

Dank der überschaubaren Datenmenge, kooperieren die Partner auch bei sehr schmalbandigen Internetverbindungen noch sehr gut über Tmate – zur Not funktioniert das auch über eine langsame 3G-Handyverbindung.

Bunt!

Die guten alten Terminal-Editoren sind allerdings inzwischen nicht (mehr?) jedermanns Sache. Und auf Windows ist die Tmate-Lösung nicht einfach zu installieren. Das ist nicht tragisch: Tatsächlich kommt mit Visual Studio Code ([4], [5]) eine richtig gute Open-Source-Lösung von Microsoft. Dieser Editor läuft auf Linux, OS X und Windows und bringt abgesehen von dem zu lang gewählten Namen tatsächlich etwas frischen Wind in die eher dröge Editoren-Welt.

In Sachen Remote Pair Programming hat Visual Studio Code ein Schmankerl in petto. Mit der Erweiterung Visual Studio Live Share (VSC, [6]) arbeiten mehrere Personen gleichzeitig an einem Projekt. Die müssen sich nach der Installation der Erweiterung einmalig bei einem zentralen Server anmelden, was zum Beispiel über einen Github-Account gelingt. Im Gegensatz zur Tmate-Lösung lässt sich dieser Server aber nicht im lokalen Netzwerk hosten. Beim Server angemeldet startet der Entwickler einen Share und bekommt dann eine URL angezeigt und direkt in die Zwischenablage kopiert. Die teilt er dem Pairing-Partner mit, wodurch dieser Zugang erhält.

Driver und Navigator können jetzt zeitgleich am Code arbeiten. Das ist wörtlich zu nehmen: Es ist möglich, mit zwei Cursors an verschiedenen Stellen in derselben Datei zu arbeiten. Oberhalb der Cursors erscheinen die Namen der jeweiligen Person. Allerdings kommt es beim normalen Pair Programming selten zu so einem Extremfall.

Sehr praktisch ist die Option, auch markierte Stellen auf beiden Seiten der Session zu sehen. Das erlaubt – bei gleichzeitigem Einsatz einer Audioverbindung – Szenarien, in denen der Navigator Code markiert, um zu zeigen, dass damit etwas nicht stimmt. Die Kommunikation über Codezeilen-Nummern entfällt so.

Angenehm ist, dass beide Teilnehmer weiterhin ihre persönlichen Lieblingsfarben und Einstellungen behalten. Beim Driver darf die Schrift weiß auf schwarz, beim Navigator zum Beispiel schwarz auf schweinchenrosa sein.

Richtig spannend wird es beim Debuggen. Der vom Driver auf seinem Computer gestartete VSC-Debugger lässt sich auch vom Navigator nutzen. Der muss dafür nicht mal die entsprechende Software (etwa Node) vorinstallieren. Beide setzen Breakpoints und durchforsten das Programm Stück für Stück.

Wer Webapplikationen entwickelt, will sich das Ergebnis der Arbeit auch mal im Browser anschauen. Dafür kann der Driver den Port (beispielsweise 8000), auf dem sein lokales System läuft, für den Navigator freischalten. Der kann dann über seinen Browser auf »http://localhost:8000« zugreifen und so die Applikation beim Driver benutzen.

Das ist für Linux-Profis technisch natürlich kalter Kaffee, aber die Einfachheit dieser Lösung und die Möglichkeit, sie über unterschiedliche Betriebssysteme hinweg zu nutzen, ist beeindruckend. Als zusätzliches Goodie darf der Driver sogar noch ein lokales Terminal teilen. Sowohl im Read-write- als auch im Read-only-Modus.

Fazit

Sowohl Tmate als auch Visual Studio Code benötigen wenig Bandbreite und bestechen mit einer gefühlten Schnelligkeit. Das Ganze stößt trotzdem an physikalische Grenzen. Eine Pairing Session zwischen Frankfurt am Main und Sydney wird immer einen Tick zähflüssiger ablaufen als die Zusammenarbeit zwischen Hamburg und München. Die Netzwerk-Latenz lässt sich nicht umgehen. Dennoch klappt Remote Pair Programming oft besser, als allein zu arbeiten. Sowohl Tmate als auch Visual Studio Code eigenen sich sehr gut dafür.