How Developers Use Relation Chains in Gerrit-Based Review Ecosystems: An Empirical Study Across Three Open-Source Ecosystems

Stellen Sie sich eine Welt vor, in der das Bauen von Software dem Konstruieren einer massiven, komplizierten Burg gleicht. In dieser Welt werfen Entwickler nicht einfach nur Ziegel gegen eine Wand und hoffen, dass sie halten; sie nutzen ein strenges System namens Code Review. Bevor irgendein neuer Ziegel (oder eine neue Zeile Code) dauerhaft zur Burg hinzugefügt wird, prüft ein Team von Inspektoren ihn auf Risse, stellt sicher, dass er zum Design passt, und achtet darauf, dass er nichts anderes beschädigt. Dieser Prozess ist entscheidend, um die Burg hoch und sicher zu halten.

Manchmal jedoch ist ein Projekt zu groß für einen einzelnen Ziegel. Es ist ein ganzer Turm, der gebaut werden muss. In der Vergangenheit versuchten Entwickler vielleicht, den ganzen Turm auf einmal zu bauen, aber das ist schwer zu inspizieren. Also begannen sie damit, ihn in eine Sequenz kleinerer, verbundener Schritte zu zerlegen. In der Softwarewelt, speziell innerhalb eines Tools namens Gerrit, werden diese verbundenen Schritte als Relation Chains bezeichnet. Betrachten Sie eine Relation Chain wie eine Reihe von Dominosteinen, die in einer Linie stehen: Während man den dritten Dominostein nicht umwerfen kann, bevor der zweite fällt, und den zweiten nicht, bevor der erste fällt, können die Inspektoren alle gleichzeitig prüfen, aber die Burg kann nur in der richtigen Reihenfolge fertiggestellt werden. Die gesamte Kette ist miteinander verknüpft; wenn der erste Dominostein (die „Basis“) wackelig ist, ist die ganze Linie in Gefahr. Das Verständnis darüber, wie diese Ketten funktionieren, ist entscheidend, denn wenn das System zu langsam oder verwirrend ist, könnten Entwickler stundenlang warten oder die Burg könnte mit versteckten Rissen gebaut werden.

---

Der Domino-Effekt: Wie Entwickler tatsächlich Code-Ketten nutzen

Dieses Paper ist eine tiefgehende Untersuchung darüber, wie Entwickler in drei massiven Open-Source-Communities (OpenStack, Wikimedia und ONAP) diese „Relation Chains“ nutzen, um Software zu bauen. Die Forscher untersuchten fast 30.000 Ketten und über 400.000 einzelne Code-Änderungen, um zu sehen, wie sich diese verknüpten Dominosteine in der realen Welt verhalten. Sie wollten wissen: Sind diese Ketten häufig? Machen sie den Review-Prozess schneller oder langsamer? Und was passiert, wenn man versucht, einen Domino in der Mitte der Linie zu reparieren?

Die Ketten sind überall (und werden größer)

Zuerst stellte die Studie fest, dass diese Ketten kein seltener Nischentrick sind, sondern eine Standardmethode der Arbeit. Je nach Projekt sind irgendwo zwischen 5 % und 49 % aller Code-Änderungen Teil einer Kette. Tatsächlich ist die Nutzung dieser Ketten in 14 von 15 untersuchten Projekten im Laufe der Zeit sogar gestiegen. Entwickler erkennen, dass das Aufteilen großer Aufgaben in verknüpfte, kleinere Stücke der richtige Weg ist.

Die meisten dieser Ketten sind kurz, meist nur ein Paar Dominosteine (eine Basis-Änderung und eine abhängige Änderung). Einige Projekte haben jedoch Ketten, die unglaublich tief reichen. Die Forscher fanden Ketten mit bis zu 98 Mitgliedern! Ein Projekt hatte sogar eine einzige, automatisch generierte Kette mit fast 60.000 Mitgliedern, obwohl dies ein Spezialfall der automatisierten Konfiguration war und nicht von Menschen geschrieben wurde.

Die „Mitte“ ist der Flaschenhals

Hier wird es interessant. Die Forscher entdeckten, dass es der schwierigste Job ist, in der Mitte einer Kette zu sein. Wenn man der erste Dominostein (die „Basis“) ist, muss man nur auf seine eigene Überprüfung warten. Wenn man der letzte ist (das „Top“), wartet man nur auf die vor einem. Aber wenn man in der Mitte ist, steckt man in einer Zange. Man wird durch den Dominostein vor einem blockiert (wartet darauf, dass dieser genehmigt wird), während man gleichzeitig die Dominosteine nach einem blockiert.

Aufgrund dieser „Zange“ dauert es signifikant länger, bis Änderungen in der Mitte einer Kette genehmigt werden. Die Studie ergab, dass Kettenmitglieder im Durchschnitt 2,6 Mal länger brauchen, um gemergt zu werden, als einzelne, isolierte Änderungen derselben Größe. Diese Verzögerung liegt nicht daran, dass der Code schlechter ist; es liegt am „Synchronisations-Overhead“. Obwohl die Inspektoren (Reviewer) die Ziegel parallel prüfen können, muss das eigentliche Mergen in die Burg nacheinander erfolgen, von unten nach oben. Jedes Mal, wenn ein Teil der Kette angepasst wird, müssen oft die gesamte Linie erneut geprüft, getestet und neu geordnet werden, was einen Flaschenhals schafft, in dem die mittleren Änderungen auf die Änderungen unter ihnen warten, während sie gleichzeitig die Änderungen über ihnen aufhalten.

Das „CI-Amplification“-Monster

Das Paper hebt auch ein Phänomen hervor, das sie den CI-Amplification-Effekt nennen. „CI“ steht für Continuous Integration, was wie eine Armee von Robotern ist, die automatisch jeden neuen Ziegel testen, um sicherzustellen, dass er die Burg nicht beschädigt. In Projekten mit strengen Regeln (wie OpenStack) muss die Roboterarmee bei jeder Aktualisierung einer Änderung in einer Kette diese Änderung und alle Änderungen, von denen sie abhängt, erneut testen.

Die Studie fand heraus, dass Kettenmitglieder 10 bis 23 automatisierte Testläufe auslösen, während eine einzelne, isolierte Änderung vielleicht nur weniger als zwei auslöst. Es ist, als müsste man sein gesamtes Haus neu testen, jedes Mal, wenn man nur eine Glühbirne austauscht. Dies erzeugt eine enorme zusätzliche Arbeit für die Computer und Verzögerungen für die Menschen.

Der „Foundation Effect“

Einer der faszinierendsten Befunde ist das, was die Autoren den Foundation Effect nennen. Sie entdeckten, dass der Aufwand, der für den ersten Dominostein (die Basis) betrieben wird, vorhersagt, wie viel Aufwand für alle nachfolgenden Dominosteine betrieben wird.

Wenn die Basis-Änderung viel Aufmerksamkeit erhält, viele Kommentare bekommt und viele Revisionsrunden durchläuft, neigt die gesamte Kette dazu, diesem Beispiel zu folgen. Die Forscher fanden eine starke Verbindung (eine Korrelation von 0,43 bis 0,61) zwischen der Aktivität auf der Basis und der Aktivität der Nachkommen. Es ist, als ob die „Vibe“ des ersten Dominosteins den Ton für die gesamte Linie angibt. Wenn das Fundament wackelig ist und viel Reparatur erfordert, dauert es länger, den gesamten Turm zu bauen. Umgekehrt, wenn die Basis solide ist und schnell genehmigt wird, fließt der Rest der Kette tendenziell reibungslos.

Ketten sind nicht statisch

Schließlich zeigt das Paper, dass diese Ketten keine starren Strukturen sind. Etwa 33,5 % der Änderungen in einer Kette durchlaufen eine „strukturelle Evolution“, bevor sie schließlich gemergt werden. Das bedeutet, dass sich die Verbindung zwischen den Dominosteinen während der Überprüfung ändert. Ein Entwickler kann entscheiden, eine Änderung von ihrem Elternteil abzukoppeln und mit einem anderen zu verknüpfen, oder die ganze Kette könnte reorganisiert werden.

Dies fügt eine weitere Ebene der Komplexität hinzu: Die Landkarte der Kette verschiebt sich ständig. Manchmal kann eine Kette lange Zeit ruhen. Die Studie fand heraus, dass die Lücke zwischen dem Einreichen eines Teils einer Kette und dem endgültigen Mergen in einigen Fällen bis zu 2,85 Jahre betragen kann!

Was dies für die Zukunft bedeutet

Die Autoren kommen zu dem Schluss, dass aktuelle Tools zur Überprüfung von Code oft jede Änderung als isoliertes Ereignis behandeln, als würde man einen einzelnen Ziegel betrachten, ohne die Wand zu sehen, zu der er gehört. Dieses Paper legt nahe, dass wir unsere Tools ändern müssen, um die „Kette“ als eine Gesamteinheit zu verstehen.

Sie schlagen vor, dass wir, wenn wir unsere Aufmerksamkeit auf die Basis der Kette (den ersten Dominostein) richten, eine enorme Menge an Zeit für den Rest der Kette sparen können. Wenn das Fundament solide ist, bewegt sich die gesamte Struktur schneller. Sie schlagen auch vor, dass Tools intelligenter mit den „Mittel“-Änderungen umgehen sollten, indem sie diese vielleicht priorisieren, um die restliche Linie freizugeben.

Kurz gesagt: Das Bauen von Software mit Relation Chains ist wie das Dirigieren eines komplexen Orchesters. Wenn der Dirigent (die Basis) den Takt verliert, kämpft das ganze Orchester. Aber wenn der Dirigent klar ist und die Musiker (die Tools) verstehen, wie die Instrumente miteinander verknüpft sind, fließt die Musik viel schneller. Die Studie legt nahe, dass wir durch das Verständnis dieser Verbindungen aufhören können, in der Schlange zu stehen, und staten Burgen viel effizienter bauen können.