Warum Pull Requests für unsere Arbeit unerlässlich sind

Achtung, heute wird es technisch! Schließlich arbeiten wir nicht nur remote und teal, sondern sind am Ende des Tages immer noch eine Agentur, die hochwertige digitale Produkte entwickelt - und für uns Techniker*innen gibt es da einige Tools, auf die wir zurückgreifen, um uns das Leben einfacher zu machen.

Heute möchten wir Euch zeigen, was Pull Requests sind und warum sie so einen hohen Stellenwert in unserer Arbeit haben.

Inhalt

1. Die Basis: Das asynchrone Arbeiten
2. Was ist ein Pull Request?
3. Pull Requests als Teil des automatischen Testens
4. Vorteile für Kund*innen
5. Vorteile für Entwickler*innen
6. Kleines Fazit

Die Entwickler*innen von /gebrüderheitz und unser Freelancer*innen-Netzwerk sind auf der ganzen Welt verteilt. Einen Frühaufsteher aus Japan mit einer Nachteule aus Deutschland in einen Termin zu bekommen, kann eine echte Herausforderung sein und ist manchmal auch nicht möglich. Um trotzdem einen wirksamen Austausch im Team zu haben, ist eine gut strukturierte und effektive asynchrone Kommunikation - also ein Austausch, der nicht in Echtzeit stattfindet - für unsere Arbeit ein Muss.

Auch Pull Requests sind ein Werkzeug, durch das wir die Kommunikation im Team erfolgreich asynchron gestalten.

Für all unseren Code setzen wir auf Git, eine Versionsverwaltung. Dreh- und Angelpunkt für den Code ist dabei die Plattform GitHub. Damit kein Wilder Code-Westen entsteht, bietet Git ein Werkzeug, das sich "Zweige" nennt. Wenn ein*e Entwickler*in am Code arbeitet, dann erstellt er*sie einen neuen Zweig - und da jedes Feature einen eigenen Zweig hat, kommen sich die Entwickler*innen nicht in die Quere. Doch natürlich müssen diese Zweige irgendwann wieder zusammengeführt werden. Und genau hier kommen die Pull Requests ins Spiel.

Wenn man beispielsweise das Feature "Bebildertes Hauptmenü" fertig gestellt hat, startet man mit einem Pull Request den Prozess, den eigenen Zweig mit dem Rest des Codes abgleichen zu lassen. Sobald dieser Pull Request geöffnet wird, kann ein*e Mit-Entwickler*in die Änderungen begutachten und abnehmen.

Bei dem Großteil unserer Projekte arbeiten wir nach Routinen, um sich wiederholende Abläufe zu automatisieren. Das fängt bei Kleinigkeiten wie dem Testen oder der Installation des Produktes an und erstreckt sich bis hin zu großen Test-Suiten, die das Produkt bis ins kleinste Detail prüfen.

Diese Tests verhindern verschiedene Fehler, die selbst den besten Programmierer*innen unterlaufen. Sei es ein fehlendes Zeichen (das kommt öfter vor, als man denkt!) oder Regressionen, - also die wiederholte Testung, damit auch im späteren Verlauf des Projekts keine Fehler entstehen - die aufgrund der Komplexität des Projektes nicht mehr von einem menschlichem Gehirn abgefangen werden können.

Nebenbei läuft in den Projekten auch noch ein Bot herum, der uns darauf hinweist, wenn es Updates für Abhängigkeiten eines Produktes gibt. Das stellt sicher, dass alles immer frisch und knackig bleibt, ohne dass jemand jeden Tag von Hand nach Updates suchen muss. Dieser Bot stellt uns dann automatisch einen Pull Request, das heißt, die potenziellen Updates werden direkt getestet - alles im Hintergrund - und wenn alles passt, ist so ein Update nur noch ein Knopfdruck für uns.

Falls Ihr mehr über automatisches Testen wissen möchtet, dann behaltet unseren Blog im Auge - hierzu wird es noch einen eigenen Artikel mit ausführlichen Informationen geben!

Auch wenn Kund*innen nicht direkt am Pull Request mitwirken, so ziehen sie einen Vorteil aus dieser Arbeitsweise: Denn bevor Features zum Testen freigegeben werden, kann das Team überprüfen, ob die Anforderungen korrekt umgesetzt wurden. Hier handelt es sich in der Regel nicht um Probleme im Verständnis des Big Pictures, sondern um Kleinigkeiten, die meist zu ungenau definiert oder oft geändert wurden. Durch den Pull Request spart Ihr Euch als Kund*in Kommunikationsaufwand und Nerven - denn dadurch, dass mehrere Menschen über den Code schauen, wird die Wahrscheinlichkeit, dass das Feature nicht richtig verstanden oder fehlerhaft gebaut wurde, enorm verringert.

Automatisches Kommunizieren von Standards

Habt Ihr schon mal eine*n neue*n Mitarbeiter*in eingearbeitet? Dabei müssen so viele Informationen kommuniziert werden, dass man schnell den Überblick verlieren kann. Und wenn man lange in einem Unternehmen ist, dann entwickelt man ja auch eine Betriebsblindheit gewissen Dingen gegenüber.

Auch hier sind Pull Requests ein tolles Tool, denn, wie oben beschrieben, laufen gewisse Tests durch - und diese geben klare Rückmeldungen über gefundene Fehler.

Wir nutzen das, um die Coding-Styles im Team gleich zu halten - denn jede*r soll den Code von anderen ja verstehen und lesen können. Das beugt übrigens auch vergessenen Zeichen vor - die je nach Programmiersprache auch Stolperfallen entstehen lassen können.

Wissen verteilen

Ein weiterer Nebeneffekt der Pull Requests ist, dass sich eine zweiter Entwickler*in mit dem Code auseinandersetzt - das hat zur Folge, dass das Wissen auf mehrere Köpfe verteilt wird.

Aber auch anders herum wird Wissen verteilt: Gibt es etwas, das am Code verbessert werden kann - zum Beispiel, weil sich die Best Practices geändert haben -, dann wird auch dieses Wissen weitervermittelt, oftmals vom Reviewenden zu der Person, die den Pull Request gestellt hat.

Mit Pull Requests gewinnen alle Teilnehmer*innen des Projekts. Sie erlauben uns, Reviews zu teil-automatisieren, regen den Austausch über Features und Wissen an und helfen uns, mit Personen auf der ganzen Welt flüssig und klar zu arbeiten. Für den*die Kund*in bringen sie ebenfalls große Vorteile, obwohl er*sie damit nie in Berührung kommt.

‍

‍