Investigating CI/CD-based Technical Debt Management in Open-source Projects
Deze studie analyseert via een grootschalig onderzoek op GitHub hoe technische schuldhulpmiddelen in CI/CD-pipelines worden geïntegreerd in open-sourceprojecten, waarbij wordt vastgesteld dat externe scripts de meest gebruikte integratiemethode zijn en 'Afwezig Feedback' de meest voorkomende configuratie-anti-patroon is.
Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer
Stel je voor dat je een enorme, levende stad bouwt. Deze stad is een softwareproject. Naarmate de stad groeit, komen er onvermijdelijk kleine problemen: een brug die niet helemaal stevig is, een weg die te smal wordt, of een gebouw dat niet voldoet aan de nieuwe brandwetten. In de programmeerwereld noemen we dit technische schuld (technical debt).
Als je deze problemen negeert, wordt de stad op den duur onbeheersbaar en kan het zelfs instorten. Maar het repareren kost tijd en geld, en vaak willen bouwers liever nieuwe gebouwen optrekken dan de oude te herstellen.
Hier komt CI/CD (Continuous Integration/Continuous Delivery) in beeld. Dit is als een automatische inspectie-robot die elke keer als er een nieuw stukje stad wordt gebouwd, direct langs komt om te controleren of alles in orde is.
Deze studie, geschreven door onderzoekers van de Universiteit van Groningen en de Universiteit van São Paulo, kijkt naar hoe deze inspectie-robots worden ingezet in duizenden open-source projecten (zoals die op GitHub). Ze wilden weten: Werken deze robots wel goed, of maken ze zelf weer nieuwe fouten?
Hier is wat ze hebben ontdekt, vertaald in alledaags taal:
1. De Robots werken, maar vaak via een "tussenpersoon"
De onderzoekers keken naar ongeveer 600.000 bouwplannen (configuratiebestanden). Ze zagen dat er veel robots (tools) zijn die technische schuld opsporen, zoals Flake8 of Shellcheck.
- Het probleem: De meeste bouwers zetten deze robots niet direct op de bouwplaats. In plaats daarvan schrijven ze een tussenpersoon (een extern script) die de robot aanstuurt.
- De analogie: Het is alsof je in plaats van zelf de lantaarnpaal te controleren, iemand anders vraagt om het te doen, en die persoon belt weer iemand anders.
- Het gevolg: Dit maakt het lastig om te zien wat er precies gebeurt. Als je de regels wilt aanpassen, moet je nu drie verschillende plekken opzoeken in plaats van één. Het is alsof je de instructies voor het bouwen van een brug in drie verschillende notitieboekjes hebt verspreid; als je één ding wilt veranderen, ben je de weg kwijt.
2. De robots staan vaak in de "verkeerde" hoek
De studie keek ook naar wanneer de robots hun werk doen.
- Goed nieuws: De meeste robots werken als een poortwachter voordat het gebouw opengaat. Als er een fout is, wordt de bouw gestopt. Dit is precies wat je wilt!
- Slecht nieuws: Veel robots staan in een naamloze hoek van het bouwplan. Ze worden niet duidelijk gemarkeerd als "Veiligheidscontrole", maar staan gewoon verpakt tussen "Bouw" en "Testen".
- De analogie: Stel je voor dat je een brandblusser hebt, maar je hebt hem in een doosje gestopt met de tekst "Dingen die we doen". Als er brand uitbreekt, zoeken mensen urenlang naar de doos in plaats van direct te grijpen. Door de robots geen duidelijke naam te geven, vergeten mensen dat ze er zijn.
3. De grootste vijand: "Niemand luistert"
Dit is misschien wel het meest opvallende resultaat. De onderzoekers vonden een enorm veelvoorkomend probleem dat ze "Afwezig Feedback" noemen.
- Wat gebeurt er? De robot doet zijn werk, ziet een fout, en... niets. Er komt geen waarschuwing, geen e-mail, geen melding op het scherm. Het is alsof de inspecteur een fout ziet, zucht, en weer wegloopt zonder iets te zeggen.
- Het resultaat: In 67% van de gevallen gebeurt dit. De bouwers weten niet dat er een probleem is, dus wordt het probleem nooit opgelost. De technische schuld blijft zich opstapelen, net als afval dat niemand opruimt omdat er geen vuilniswagen komt.
4. Andere gevaarlijke gewoontes
Naast het niet melden van fouten, zagen ze nog twee andere slechte gewoonten:
- De "Laat-merging" valkuil: Soms wachten ze met controleren tot het gebouw al volledig is samengevoegd met de rest van de stad. Dan is het te laat om makkelijk te repareren; je moet nu de hele stad slopen om het te fixen.
- De "Laat-falen" valkuil: Soms staat er in het bouwplan: "Als de robot een fout ziet, negeer het dan gewoon." Dit is alsof je zegt: "Als de brandblusser niet werkt, doe dan alsof er geen brand is." Dit gebeurt vaak bij tools die alleen kijken naar de "stijl" van de code, en niet naar de ernstige fouten.
Wat betekent dit voor de toekomst?
De onderzoekers concluderen dat we de robots beter moeten leren gebruiken.
- Maak ze zichtbaar: Geef de controles duidelijke namen, zodat iedereen weet dat ze er zijn.
- Luister naar de meldingen: Zorg dat als de robot een fout ziet, er direct een belletje gaat. Geen melding = geen oplossing.
- Houd het simpel: Probeer de robots direct te koppelen aan het bouwplan in plaats van via ingewikkelde tussenpersonen.
Kortom: We hebben de technologie om technische schuld te vinden, maar we zijn vaak te lui of te slordig om te luisteren naar wat de robots ons vertellen. Als we dat veranderen, kunnen we onze softwaresteden veilig en gezond houden.
Verdrinkt u in papers in uw vakgebied?
Ontvang dagelijkse digests van de nieuwste papers die bij uw onderzoekswoorden passen — met technische samenvattingen, in uw taal.