Unser Team besteht aktuell aus 9 Entwicklern. Einige davon arbeiten dauerhaft im Home Office, aber auch die restlichen nehmen sich regelmäßig die Freiheit, von zu Hause zu arbeiten. Code Reviews wurden immer weniger aufgrund der verteilten Arbeit und der steigenden Breite an Arbeitsthemen.

Um sowohl die Code Qualität wieder etwas zu verbessern als auch mehr Wissensaustausch in fachlichen und technischen Themen zu fördern, haben wir uns entschieden vermehrt auf GitHub Pull-Requests (PR) zu setzen.

Aller Anfang ist schwer

Startet man mit der Arbeit mit Pull-Requests, kann man sich schnell überlastet fühlen. Gefühlt erhielten wir alle paar Minuten eine neue Mail, welche zu einem Pull-Request aufforderte oder einen neuen Kommentar innerhalb einer Pull-Request Diskussion mitteilte. Ständig wurden wir aus der eigenen Arbeit rausgeworfen und hatten das Gefühl, auf diese Anfrage eingehen zu müssen. Manche Diskussionen wurden zu einer Code-Zeile geführt und wurden recht umfangreich oder nur mit Smileys (Zustimmung/Ablehnung) geführt. Es ist vergleichbar mit dem Informationsoverload, der bisweilen bei Slack auftritt.

Beim Erstellen der ersten eigenen Pull-Requests mussten wir uns auch daran gewöhnen, dass ein Review etwas auf sich warten lässt. Schließlich hat der Reviewer auch nicht ständig Zeit. Das störte unseren Tagesablauf beträchtlich: Warten auf die Reaktion der Kollegen. Das Problem der asynchronen Kommunikation gilt auch für geführte Diskussionen innerhalb eines Pull-Requests. Wenn nun noch Anfragen zu mehreren Projekten reinkommen, ist noch mehr Kontextwechsel als ohnehin schon in der täglichen Arbeit. Das große Rauschen.

Eine weitere Feststellung über die Anfänge mit Pull-Requests ist, dass manche dazu neigen, Pull-Requests zu recht umfangreichen Commits erfragen. Solche Reviews gestalten sich meist als schwieriger und die Oberfläche von GitHub macht dies noch unübersichtlicher als man es von IntelliJ IDEA gewohnt ist. Bei solchen Reviews sind oft Sprünge zwischen Dateien, Methoden oder Klassen notwendig sowie Wechsel zwischen Test und Implementierung oder zu ähnlich gestrickten Services um Konsistenz zu prüfen - dies ist mit der GitHub-Oberfläche nicht möglich.

Ein weiterer, wenn auch nur kleiner Blocker, ist die TeamCity Integration auf GitHub. Hier muss jede Connection für jedes Projekt leider manuell angelegt werden. Benennt man das Goal zum Testen des Pull-Requests noch um, muss dies auch explizit noch einmal in GitHub nachgezogen werden. Das fühlt sich nicht rund an.

Warum also Pull-Requests?

Sicher bringt die Arbeit mit Pull-Requests einige Herausforderungen mit sich. In einer Austauschrunde im Team wurden aber vor allem die Vorteile deutlich. Es fühlt sich einfach gut an. Endlich machen wir wieder mehr Reviews und das sogar vor dem Live-Gang eines Features. Wir schauen wieder gemeinsam auf den Code. Es macht Spaß damit zu arbeiten. Wenn Diskussionen mal ausarten oder weiteres Feedback notwendig ist, lassen sich andere Kollegen auch bequem und spontan in die Diskussion integrieren.

Durch die Reviews kommen Diskussionen zu technischen Problemen hoch, die mit unserem bisherigen Remote-Workflow so nicht stattgefunden haben. Wir erachten diese Reviews als sehr wertvoll. Wir erhoffen uns auch großes Potential für die Arbeit mit bzw. Einarbeitung neuer Kollegen, die komplett remote arbeiten. Durch die Arbeit in GitHub (anstatt eines firmeninternen Gitrepos) müssen weniger Barrieren wie beispielsweise VPN überwunden werden.

Pull-Requests auf GitHub ermöglichen auch das Vorgehen und entsprechende Entscheidungen in Diskussionen für den späteren Bedarf zu dokumentieren. Dies ist sehr wertvoll um noch einmal zu prüfen, warum eine bestimmte Richtung gewählt wurde. Auch sind die Commits in der Regel schöner gestaltet, da hier vermehrt Änderungen gesammelt werden und diese im Anschluss als ein Paket gesquashed werden können.

Auch positiv ist die bereits erwähnte TeamCity Integration. Diese kann einen build durchführen, wobei schon der mit dem Master gemerged Code getestet wird. Erst wenn dies erfolgreich ist, darf der Branch dann per Mausklick vom Nutzer in den Master überführt werden. Die GitHub-Oberfläche zeigt sich für diesen Prozess meist sehr komfortabel. Das Vorgehen über die TeamCity Integration kann so auch die Zeit für das lokale Ausführen von Integrationstests sparen.

Einen besonderen Reiz hat das Einbinden der Business Analysten in die Pull-Requests. Treten fachliche Fragen auf, so können diese durch die BAs innerhalb der Diskussion mit geklärt werden und diese Entscheidungen sind somit näher am Code dokumentiert.

Wir haben einiges gelernt

Wir werden zukünftig intensiver mit Pull-Requests auf GitHub arbeiten. Damit auch Neulinge schneller Fahrt aufnehmen können, haben wir ein paar Best Practices gesammelt, die ich hiermit gerne teilen möchte.

Durch Warten auf Reaktionen nicht den eigenen Rhythmus behindern lassen

  • Erwartete Antwortzeit im Team ausmachen
  • bei dringenden Requests die Reviewer direkt anpingen
  • mehrere Reviewer wählen, um schneller ein Review zu erhalten - kann aber auch zu einer Mehrbelastung bei den Reviewern führen ;)

Flut an Änderungen und Anfragen per Mail meistern

  • wenn durch Diskussionen im Sekundentakt neue Benachrichtigungen eintrudeln erstmal kurz zurückhalten und wenn die Diskussion sich beruhigt hat und man selbst auch wirklich die Zeit, dann in die Diskussion einsteigen
  • Reviews in GitHub nutzen um mehrere einzelne Kommentare zusammenzufassen
  • Benachrichtigung-Einstellungen in GitHub anpassen
  • Nachrichten in Outlook in extra Ordner verschieben und diesen in bestimmten Zeitabständen prüfen
  • Kommentare in GitHub-Diskussionen auf das Nötigste beschränken - Fortgang der Diskussion oder konstruktives Feedback (keine Thumbs up oder wird gemacht Floskeln)
  • sobald der Fokus der Diskussionen den Rahmen des PR verlässt (z.B. neue Feature Ideen), dann die Diskussion auslagern (Slack, neue Pull-Request, Issues etc.)

Überblick behalten

  • Pull-Request Autor sollte selbst mergen
  • offene Diskussionen lassen sich auch in GitHub gut anzeigen -> Pull-Requests -> Mentioned -> auf der linken Seite werden ungelesene Themen angezeigt
  • Squash und Force Push um Commits übersichtlicher zu machen
  • abhängige PR in unterschiedlichen Projekten sollten auch verlinkt werden (Projekt A PR5 wartet auf Projekt B PR3)
  • möglichst kleine Pull-Requests erzeugen

Pull-Requests im ganzen Team leben

  • Pull-Request Neulingen im Rahmen einer Story einen Pull-Request Erfahrenen zur Seite stellen, um schnell auf die Fragen und Ängste des Neulings einzugehen. Das hat sich tatsächlich bei uns bewährt :)
  • Best Practices niederschreiben, um Neulingen den Einstieg zu erleichtern und einheitliches Vorgehen im Team zu haben

Pull Requests automatisiert prüfen lassen

  • TC Goals anlegen, welche den Merge des Pull-Requests in den Master automatisiert testen