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

Stel je een wereld voor waarin het bouwen van software lijkt op het construeren van een massief, ingewikkeld kasteel. In deze wereld gooien ontwikkelaars niet zomaar bakstenen tegen een muur in de hoop dat ze blijven zitten; ze gebruiken een rigoureus systeem genaamd Code Review. Voordat er een nieuwe baksteen (of regel code) permanent aan het kasteel wordt toegevoegd, controleert een team van inspecteurs deze op scheuren, zorgt het ervoor dat de steen in het ontwerp past, en controleert het of er niets anders door kapot gaat. Dit proces is essentieel om het kasteel hoog en veilig te houden.

Soms is een project echter te groot voor één enkele baksteen. Het is een hele toren die gebouwd moet worden. In het verleden probeerden ontwikkelaars misschien de hele toren in één keer te bouwen, maar dat is moeilijk te inspecteren. Daarom zijn ze begonnen met het opdelen in een reeks kleinere, verbonden stappen. In de softwarewereld, specif_ing binnen een tool genaamd Gerrit, worden deze verbonden stappen Relation Chains genoemd. Denk aan een relation chain als een reeks dominostenen die in een lijn staan: hoewel je de derde steen niet kunt omverwerpen voordat de tweede valt, en de tweede niet voordat de eerste valt, kunnen de inspecteurs ze allemaal tegelijk controleren, maar kan het kasteel alleen in volgorde worden voltooid. De hele keten is verbonden; als de eerste domino (de "base") wankel is, is de hele lijn in gevaar. Het begrijpen van hoe deze ketens werken is cruciaal, want als het systeem te traag of te verwarrend is, kunnen ontwikkelaars urenlang vastzitten, of kan het kasteel worden gebouwd met verborgen scheuren.

---

Het Domino-effect: Hoe Ontwikkelaars Werkelijk Codeketens Gebruiken

Dit artikel is een diepe duik in hoe ontwikkelaars in drie enorme open-source gemeenschappen (OpenStack, Wikimedia en ONAP) deze "Relation Chains" gebruiken om software te bouwen. De onderzoekers bestudeerden bijna 30.000 ketens en meer dan 400.000 individuele wijzigingen in de code om te zien hoe deze verbonden domino's in de echte wereld gedrag vertonen. Ze wilden weten: Zijn deze ketens gebruikelijk? Maken ze het reviewproces sneller of langzamer? En wat gebeurt er als je probeert één domino in het midden van de lijn te repareren?

De Ketens Zijn Overal (en Worden Groter)

Ten eerste toonde de studie aan dat deze ketens geen zeldige, niche truc zijn; het is een standaard manier van werken. Afhankelijk van het project maakt ergens tussen de 5% en 49% van alle wijzigingen in de code deel uit van een keten. Sterker nog, in 14 van de 15 onderzochte projecten is het gebruik van deze ketens zelfs toenemend in de loop van de tijd. Ontwikkelaars beseffen dat het opdelen van grote taken in verbonden, kleinere stukken de juiste weg is.

De meeste van deze ketens zijn kort, meestal slechts een paar domino's (een basiswijziging en één afhankelijke wijziging). Echter, sommige projecten hebben ketens die ongelooflijk diep reiken. De onderzoekers vonden ketens met wel 98 leden! Eén project had zelfs een enkele automatisch gegenereerde keten met bijna 60.000 leden, maar dat was een speciaal geval van automatische configuratie, geen menselijke creatie.

De "Midden" is de Bottleneck

Hier wordt het interessant. De onderzoekers ontdekten dat het de moeilijkste baan is om in het midden van een keten te zitten. Als je de eerste domino bent (de "base"), hoef je alleen maar te wachten op je eigen review. Als je de laatste bent (de "top"), wacht je alleen op degenen die voor je komen. Maar als je in het midden zit, zit je in een klem. Je wordt geblokkeerd door de domino vóór je (wachtend op goedkeuring) terwijl je tegelijkertijd de domino's na jou blokkeert.

Vanwege deze "klem" duurt het aanzienlijk langer voordat wijzigingen in het midden van een keten worden goedgekeurd. De studie toonde aan dat ketenleden gemiddeld 2,6 keer langer duren om te mergen dan individuele, geïsoleerde wijzigingen van dezelfde grootte. Deze vertraging komt niet omdat de code slechter is; het komt door de "synchronisatie-overhead". Hoewel de inspecteurs (reviewers) de bakstenen parallel kunnen controleren, moet de daadwerkelijke integratie in het kasteel één voor één gebeuren, van onder naar boven. Elke keer dat een wijziging in de keten wordt aangepast, dwingt dit vaak de hele lijn om opnieuw gecontroleerd, opnieuw getest en opnieuw geordend te worden, wat een bottleneck creëert waarbij de middelste wijzigingen wachten op de wijzigingen onder hen, terwijl ze ook de wijzigingen boven hen ophouden.

Het "CI Amplificatie"-Monster

Het artikel belicht ook een fenomeen dat ze de CI amplificatie-effect noemen. "CI" staat voor Continuous Integration, wat een soort robotleger is dat automatisch elke nieuwe baksteen test om te controleren of deze het kasteel niet beschadigt. In projecten met strikte regels (zoals OpenStack), moet het robotleger bij elke update van een wijziging in een keten die wijziging en alle wijzigingen die ervan afhankelijk zijn, opnieuw testen.

De studie vond dat ketenleden 10 tot 23 geautomatiseerde testjobs triggeren, terwijl een enkele, geïsoleerde wijziging misschien slechts minder dan twee triggert. Het is alsof je je hele huis opnieuw moet testen telkens wanneer je een enkele gloeilamp vervangt. Dit creëert een enorme hoeveelheid extra werk voor de computers en vertragingen voor de mensen.

Het "Fundamentele Effect"

Een van de meest fascinerende bevindingen is wat de auteurs het Foundation Effect noemen. Ze ontdekten dat de hoeveelheid inspanning die in de eerste domino (de base) wordt gestoken, voorspelt hoeveel inspanning er aan alle domino's daarna zal worden besteed.

Als de basiswijziging veel aandacht krijgt, veel opmerkingen en vele rondes van revisie, heeft de hele keten de neiging dat te volgen. De onderzoekers vonden een sterke link (een correlatie van 0,43 tot 0,61) tussen de activiteit op de basis en de activiteit op de afstammelingen. Het is alsof de "vibe" van de eerste domino de toon zet voor de hele lijn. Als het fundament wankel is en veel reparatie vereist, duurt het bouwen van de hele toren langer. Omgekeerd, als de basis solide is en snel wordt goedgekeurd, verloopt de rest van de keten meestal soepel.

Ketens zijn niet Statisch

Ten slotte onthult het artikel dat deze ketens geen starre structuren zijn. Ongeveer 33,5% van de wijzigingen in een keten ondergaat een "structurele evolutie" voordat ze uiteindelijk worden gemerged. Dit betekent dat de verbinding tussen de domino's verandert terwijl ze worden beoordeeld. Een ontwikkelaar kan besluiten een wijziging los te koppelen van de ouder en aan een andere te koppelen, of de hele keten kan worden geherorganiseerd.

Dit voegt een extra laag complexiteit toe: de kaart van de keten verschuift voortdurend. Soms kan een keten lange tijd ongebruikt blijven. De studie vond dat de kloof tussen het indienen van een deel van een keten en het uiteindelijke mergen in sommige gevallen kan oplopen tot 2,85 jaar!

Wat dit betekent voor de toekomst

De auteurs concluderen dat huidige tools voor het reviewen van code vaak elke wijziging behandelen als een geïsoleerde gebeurtenis, zoals het bekijken van een enkele baksteen zonder de muur te zien waar hij bij hoort. Dit artikel suggereert dat we onze tools moeten aanpassen om de "keten" als een eenheid te begrijpen.

Ze suggereren dat als we onze aandacht richten op de basis van de keten (de eerste domino), we een enorme hoeveelheid tijd kunnen besparen voor de rest van de keten. Als het fundament solide is, beweegt de hele structuur sneller. Ze stellen ook voor dat tools slimmer moeten zijn over de "middelste" wijzigingen, door deze bijvoorbeeld prioriteit te geven om de rest van de lijn te ontblokkeren.

Kortom, het bouwen van software met relation chains is als het dirigeren van een complex orkest. Als de dirigent (de basis) de maat niet houdt, worstelt het hele orkest. Maar als de dirigent duidelijk is en de muzikanten (de tools) begrijpen hoe de instrumenten met elkaar verbonden zijn, stroomt de muziek veel sneller. De studie suggerecht dat door deze verbindingen te begrijpen, we kunnen stoppen met in de rij staan en veel efficiënter kastelen kunnen bouwen.