Seite 3: Eine Frage des Typs

Inhaltsverzeichnis

Entwickler sind Menschen und ein Pull-Request-Workflow erfordert Interaktion. Die folgenden Tipps und Hinweise auf Basis pointierter Typprofile sollen helfen, einen akzeptablen und wirkungsvollen Pull-Request-Workflow zu etablieren und den Umgang mit häufig auftretenden Problemen zu meistern.

Der Kritiker: Er begreift Pull Requests als essenziellen Teil seiner Arbeit und überprüft jeden Pull Request sofort. Das bindet einen Großteil seiner Zeit, worunter die eigene Zuarbeit zu Storys aus dem Sprint leidet.

Ein solches Verhalten ist sicherlich Thema in einer Retrospektive. Eine Lösungsmöglichkeit ist die gezielte Nominierung der Reviewer. Eine weitere Option ist die Beschränkung auf maximal einen Review pro Tag und Entwickler.

Der Stumme: Er hat keine Meinung oder empfindet Pull Requests als störend. Einen Review führt er allenfalls nach Aufforderung durch. Andere Kollegen müssen einspringen, wodurch sich der Review-Prozess verzögert.

Hier hilft auch die Retrospektive und ein sich hoffentlich entwickelndes Verständnis vom Mehrwert, den Pull Requests bieten. In der Regel gleicht sich das Review-Verhalten immer weiter an, je länger ein Team zusammenarbeitet. Es bleibt eine stetige Herausforderung für jedes Team eine Mischung aus Code-Review und der eigentlichen Entwicklung zu finden. Um es den Reviewern dabei so leicht wie möglich zu machen, helfen kompakt gehaltene Pull Requests, gute Beschreibungstexte, Screenshots bei UI-Änderungen oder auch Begründungen für Entscheidungen.

Der Abnicker: Er sieht sich gern Pull Requests an und genehmigt die meisten sofort. Nur gelegentlich erfolgt eine Anmerkung und wenn dies geschieht ist der Mehrwert überschaubar.

Dieses Verhalten ist oft bei Junior-Entwicklern zu beobachten, die zwar gern Code der erfahreneren Kollegen lesen, aber wenig beizutragen haben. Letztlich ist dies auch nachvollziehbar. Unzureichende Teilnahme ist natürlich auch ein Hinweis auf Schulungsbedarf. Der Autor kann Feedback fördern, indem er Stellen kennzeichnet, bei dener er sich nicht sicher ist beziehungsweise Feedback wünscht.

In eingespielten Teams werden Pull Requests oft von erfahrenen Entwicklern schnell genehmigt, da sie sich bereits einen guten Ruf erarbeitet haben. Hier ist es eine Frage der Disziplin, auch deren Code entsprechend zu prüfen – jeder macht Fehler und Verbesserungspotenzial gibt es eigentlich immer.

Der Tüftler: Er vergräbt sich gern in komplexe Themen und teilt diese nur selten in kleinere Unteraufgaben. Alle Tests sind stets sauber, komplett und dokumentiert, bevor er einen Pull Request erstellt. Leider führt dies dazu, dass die Pull Requests umfangreich sind und erst nach mehreren Tagen vorliegen. Die Reviewzyklen dauern lange und Features lassen sich häufig nicht mehr im Rahmen des Sprints abnehmen, da die Zeit nicht ausreicht.

Das kommt recht häufig vor und verlangt vom Team ein gemeinsames Abwägen zwischen Pragmatismus und technischer Exzellenz. Ein guter Mittelweg ist die Erstellung eines technischen Gerüsts (Scaffolding) mit dem technischen Lösungsansatz ohne Feinarbeit und Tests. Das muss natürlich etwa über ein eindeutiges Tag wie [WIP] (Work-in-Progress) gekennzeichnet werden. In der Regel kommt hier auch der meiste Input. Die weitere Arbeit mit Struktur, Optimierung, Kommentaren und Tests erfolgt nachgelagert, sofern der Grundansatz diskutiert und abgesegnet ist. Weitere Pull Requests fallen dann auch automatisch kleiner aus.

Der Kenner: Er verbringt viel Zeit in Reviews und hat stets viele Anmerkungen, die sachlich und fachlich korrekt sind. Er kennt alternative Bibliotheken, weist auf Blogposts oder Design Patterns hin und merkt alternative Lösungsansätze an. Die Diskussion mit ihm kostet aber viel Zeit und verbessert das Ergebnis nur wenig.

Auch dieses Verhalten ist nicht selten und der Input natürlich grundsätzlich wertvoll. In der IT gibt es nahezu immer mehrere Wege, die zum Ziel führen, sodass im Zweifel entscheidend ist, ob die vom Autor gewählte Lösung den Anforderungen genügt und Alternativen keine signifikanten Vorteile versprechen.

Reviewer sollten Kommentare selbst einstufen, damit der Feedback-Loop effizient bleibt. Folgende Level sind denkbar:

• Blocker: Hier muss unbedingt nachgearbeitet werden, da Anforderungen nicht erfüllt sind oder beispielsweise Sicherheitslücken und/oder Performanceeinbußen entstehen. Der Pull Request wird abgelehnt.
• Suggestion: Eine Empfehlung beispielsweise für eine alternative Library oder einen weiteren Integrationstest. Der Reviewer sollte dies begründen. Pull Request wird aber genehmigt, der Autor entscheidet also, ob er dem Kommentar folgt oder nicht.
• Minor: Kleinere Anmerkungen wie Fehler bei Einrückung oder Typo. Pull Request wird ebenfalls genehmigt.

Als Konvention empfiehlt es sich, die Einordnung als erstes Wort des Kommentars im Pull Requests zu setzen – so wie auch die Ticketnummer in einem Commit-Kommentar am Anfang steht.

Verhalten und Entscheidungen bei Konflikten

Konflikte sind normal, da jeder Entwickler eigene Vorkenntnisse, Präferenzen und Schwerpunkte hat. Eine gewisse "Storming"-Phase ist daher bei Einführung eines Pull-Request-Workflows auch zu akzeptieren. Letztlich geht es nur über eine gesunde Kommunikationskultur mit gegenseitigem Respekt. Sofern eine Diskussion aber ausufert, sollten sich die Kollegen persönlich besprechen, anstatt die Auseinandersetzung in endlosen Threads in den Kommentaren ausufern zu lassen. Kommt keine Einigkeit zustande, sollten weitere Kollegen hinzugezogen werden. Um eine Diskussion abzukürzen, kann je nach Thema auch eine Umfrage im Chat helfen – beispielsweise mit dem Poll-Plug-in von Slack.

Grundsätzlich hilft vor allem die Retrospektive, das gemeinsame Vorgehen und den Prozess immer weiter zu schärfen. Findet sich keine Lösung, muss im Zweifel der Product Owner auf Basis der Fachlichkeit und der entstehenden oder entstandenen Aufwände und Konsequenzen entscheiden. In einem konstruktiv und mit gegenseitigem Respekt arbeitenden Team dürfte das aber nur selten notwendig sein.