Beyond the Tip of the Iceberg: Understanding SATD in Dockerfiles through the Lens of Co-evolution
Diese Studie zeigt, dass die Analyse selbstzugegebener technischer Schulden (SATD) in Dockerfiles ausschließlich aus der Perspektive einer einzelnen Datei unvollständig ist, da ein erheblicher Teil der Einträge und Tilgungen technischer Schulden mit Änderungen am Quellcode verknüpft ist, wobei Probleme mit externen Abhängigkeiten die Einträge antreiben und architektonisches Refactoring die Tilgungen ermöglicht.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich vor, Sie bauen eine komplexe Maschine, wie etwa eine High-Tech-Kaffeemaschine. Um sicherzustellen, dass sie jedes Mal perfekt funktioniert, schreiben Sie eine detaillierte Bedienungsanleitung (die Dockerfile), die der Fabrik genau vorgibt, wie die Maschine zu montieren ist, welche Teile zu verwenden sind und wie sie zu verpacken ist.
Manchmal sind die benötigten Teile jedoch noch nicht fertig, oder die Fabrikhalle hat eine seltsame Regel, die Ihr Design durchbricht. Also notieren Sie einen Vermerk in der Anleitung: „Hey, dieses Teil ist vorübergehend, weil das echte noch nicht fertig ist. Wir werden das später beheben." In der Tech-Welt heißt dieser Vermerk Selbstzugegebene Technische Schulden (SATD). Es ist ein Entwickler, der sagt: „Ich weiß, dass dies ein provisorischer Workaround ist, und ich verspreche, ihn irgendwann aufzuräumen."
Die alte Betrachtungsweise
Frühere Studien betrachteten diese „Schulden-Notizen", indem sie lediglich die Bedienungsanleitung selbst lasen. Sie fragten: „Um welche Art von Notiz handelt es sich? Geht es um ein fehlendes Teil? Ist es eine Sicherheitskorrektur?" Sie behandelten die Anleitung so, als ob sie im luftleeren Raum existiere, und ignorierten alles andere, das in der Fabrik geschah.
Die neue Perspektive: Die „Eisberg"-Sichtweise
Diese Arbeit argumentiert, dass das reine Lesen der Anleitung so ist, als würde man nur die Spitze eines Eisbergs betrachten. Die wahre Geschichte verbirgt sich unter Wasser. Die Autoren schlagen vor, dass diese „Schulden-Notizen" in der Anleitung fast immer durch Änderungen in den tatsächlichen Maschinenteilen (dem Quellcode) oder in der Lieferkette der Fabrik (anderen Konfigurationsdateien) verursacht oder behoben werden.
Um dies zu beweisen, agierten die Forscher wie Detektive. Sie lasen nicht nur die Anleitungen, sondern betrachteten die gesamte „Commit-Historie" von 393 verschiedenen Projekten. Sie verfolgten jedes Mal, wenn eine Notiz hinzugefügt oder entfernt wurde, und fragten: „Was änderte sich in der Fabrik genau in diesem selben Moment noch?"
Was sie fanden (Die großen Entdeckungen)
Die Notizen sind verbunden: In etwa 27 % der Fälle, in denen eine neue „Schulden-Notiz" geschrieben wird, liegt dies daran, dass etwas anderes im Projekt kaputtging oder sich änderte. Noch interessanter ist, dass in 40 % der Fälle, in denen eine Notiz entfernt wird (die Schuld wird beglichen), dies darauf zurückzuführen ist, dass eine Änderung an anderer Stelle im Projekt stattfand, die es endlich ermöglichte, die Anleitung zu korrigieren.
- Analogie: Stellen Sie sich vor, Sie schrieben eine Notiz: „Verwenden Sie einen Plastikbecher, weil der Glasbecher kaputt ist." Sie beheben die Notiz nicht, indem Sie sie einfach auslöschen; Sie beheben sie, indem Sie tatsächlich neue Glasbecher beim Lieferanten bestellen. Die Notiz und die neuen Becher bilden ein Paar.
Einige Schulden werden schneller beglichen: Man könnte denken, dass ein Problem, das kompliziert ist und viele verschiedene Teile der Fabrik betrifft, länger dauert, um behoben zu werden. Überraschenderweise fanden die Forscher das Gegenteil. Wenn eine „Schulden-Notiz" mit Änderungen in anderen Dateien verknüpft ist, wird sie schneller beglichen als Notizen, die für sich allein stehen.
- Warum? Weil, wenn ein Problem das gesamte System betrifft, das Team es als dringenden Notfall mit hoher Priorität behandelt. Sie scharen sich zusammen, um es schnell zu beheben.
- Die Ausnahme: Das einzige Mal, dass diese „verknüpften" Schulden länger anhielten, war, wenn die Notiz eine fehlende Funktion betraf (z. B. „Wir brauchen einen neuen Knopf, der noch nicht existiert"). Diese Art von Schuld braucht Zeit zum Aufbau, egal wie viel Aufmerksamkeit man ihr schenkt.
Warum die Notizen erscheinen (Die Auslöser): Die Forscher kategorisierten, warum diese Notizen geschrieben werden. Die häufigsten Gründe waren:
- Warten auf den Lieferanten: Die Teile (Software-Bibliotheken), die das Team benötigt, wurden noch nicht offiziell veröffentlicht, sodass sie eine vorübergehende, unordentliche Lösung verwenden müssen.
- Fabrik-Mismatches: Die Anweisungen entsprechen nicht den aktuellen Regeln der Fabrik (z. B. hat die Fabrik ihr Betriebssystem aktualisiert und die alten Anweisungen funktionieren nicht mehr).
- Unvollendete Arbeit: Das Team begann eine Funktion, konnte sie aber nicht abschließen, und hinterließ daher eine „TODO"-Notiz.
Wie die Notizen entfernt werden (Die Behebungen): Um die Schulden zu tilgen, musste das Team normalerweise eines von drei Dingen tun:
- Auf den Lieferanten warten: Der übergeordnete Teil wurde schließlich veröffentlicht, und sie konnten auf das echte Teil wechseln.
- Die Fabrik umgestalten: Sie entwarfen den Aufbau der Maschine komplett neu (Refactoring), wodurch der vorübergehende Workaround unnötig wurde.
- Die Funktion fertigstellen: Sie bauten schließlich den fehlenden Teil, über den die Notiz klagte.
Das Fazit
Die wichtigste Lehre für jeden, der Software entwickelt, lautet: Betrachten Sie die Bedienungsanleitung nicht isoliert.
Wenn Sie diese „Schulden-Notizen" finden, beheben oder verhindern wollen, müssen Sie das Gesamtbild betrachten. Sie müssen sehen, wie sich die Anleitung zusammen mit dem Code, den Tests und den Build-Tools verändert. Wenn Sie nur die Anleitung betrachten, verpassen Sie die wahren Gründe, warum die Schulden existieren, und wie man sie tatsächlich beseitigt. Es ist, als würde man versuchen, eine Kaffeemaschine zu reparieren, indem man nur das Rezept betrachtet, ohne jemals zu prüfen, ob die Kaffeebohnen frisch sind oder ob der Wasserdruck stimmt.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.