Technische Schulden: Meine Rust-Bibliothek ist jetzt ein CDO

Technische Schulden: Meine Rust-Bibliothek ist jetzt ein CDO

• Als Witz über technische Schulden gibt es die Pointe, dass es, wenn es technische Schulden gibt, auch Derivate geben müsse, um diese Schulden zu handhaben.
• Das Rust-Ökosystem bringt eine Lösung hervor, die so wirkt, als würde sie technische Schulden verbriefen.
• Zum Beispiel hängt eine Bibliothek stuff von einer anderen Bibliothek learned-rust-this-way ab, doch der Autor von learned-rust-this-way verliert das Interesse, und Probleme beginnen sich anzusammeln.

Die Realität technischer Schulden

• learned-rust-this-way gilt als technische Schuld; sie verursacht nicht unmittelbar Probleme, ist aber dennoch eine Schuld.
• Irgendwann erkennt jemand, dass learned-rust-this-way eine Schuld ist, und da der ursprüngliche Autor nicht erreichbar ist, wird sie der RUSTSEC-Datenbank hinzugefügt.
• RUSTSEC bewertet als Rating-Agentur diese Schuld als Müll, wodurch bei vielen Menschen die CI (Continuous Integration) zu scheitern beginnt.

Wie sich die Schuld lösen lässt

• Als Maintainer von stuff steigt der Stress, wenn Nutzer Probleme mit der Verwendung von learned-rust-this-way ansprechen, und es wird verlangt, Maßnahmen zum Umgang mit der Schuld zu ergreifen.
• Der Umstieg auf eine Alternative ist eine Option, aber in diesem Fall sind alle Alternativen unattraktiv.
• Wenn man learned-rust-this-way forkt, steht man vor denselben Anforderungen; das ist nur eine vorübergehende Lösung und behebt das Problem nicht.

Eine Lösung, die tatsächlich funktioniert

• Wenn man den betreffenden Code in die eigene Bibliothek integriert, wird diese wertlose technische Schuld plötzlich mit „AAA“ bewertet.
• Man fasst den Code danach nicht mehr an, verschweigt die Zusammenführung und pflegt die Bibliothek wie zuvor weiter, und die Welt dreht sich weiter.
• Durch das Vendoring und Integrieren von yaml-rust in insta wurde daraus eine Kombination aus insta-Code und yaml-rust, wodurch die technische Schuld auf AAA hochgestuft wurde.

Meinung von GN⁺

• Dieser Artikel vergleicht technische Schulden mit Finanzderivaten und erklärt damit auf geistreiche Weise Probleme, die in der Softwareentwicklung entstehen.
• Technische Schulden sind ein häufiges Problem in der Softwareentwicklung, und der Artikel zeigt Entwicklern kreative Wege auf, mit diesen Schulden umzugehen.
• Bewertungssysteme im Rust-Ökosystem wie RUSTSEC können Entwicklern helfen, die Stabilität von Bibliotheken einzuschätzen, zugleich aber auch unnötigen Stress verursachen.
• Das Zusammenführen von Code zur Lösung technischer Schulden kann eine vorübergehende Maßnahme sein; langfristig ist eine nachhaltige Wartungsstrategie erforderlich.
• In solchen Situationen sollten verschiedene Lösungen in Betracht gezogen werden, etwa community-getriebene Wartung, Co-Maintenance von Open-Source-Projekten oder die Suche nach Ersatzversionen einer Bibliothek.

[GN⁺]

Hacker-News-Kommentare

• Der Autor des beliebtesten YAML-Parsers hat das Projekt plötzlich aufgegeben und es als deprecated und unmaintained markiert. Das geschah ohne Vorwarnung und ohne einen anderen Maintainer zu benennen; das Paket funktioniert zwar weiterhin, wird aber noch in mehr als 4000 anderen Crates verwendet, sodass Audit- und Auto-Update-Tools vor der Nutzung eines nicht gewarteten Crates warnen werden.
• Für alle, die über die Abkürzung CDO verwirrt waren: Vermutlich bedeutet sie „collateralized debt obligation“. Dafür spricht, dass das Wort „collateralized“ mehrfach verwendet wurde.
• Wenn ein verwundbarer Codepfad nicht von externen Bibliotheken ausgeführt oder erreicht werden kann, dann ist das ein sicherer Codepfad. Das Vendoring einer Bibliothek liefert Werkzeuge, um den Code anzugreifen, und wenn die Testabdeckung der eigenen Bibliothek ausreichend ist, kann man Code-Coverage-Tools auch auf die eingebundene Bibliothek anwenden. Die eingebundene Bibliothek zu verändern kann herausfordernd sein, aber Teile zu löschen, die man nicht braucht, könnte vergleichsweise einfach sein. Das hängt natürlich von der Struktur der eingebundenen Bibliothek ab.
• Ein ehemaliger Quant-Analyst und heutiger Ökonom lobt den Autor dafür, den Begriff „Collateralized Debt Obligation“ korrekt verwendet zu haben. Er möchte einen Artikel über „technische Schulden“ schreiben, hält die Metapher von „Schulden“ für dieses Konzept aber nicht für passend. „Hochviskoser Code“ könnte der bessere Ausdruck sein. Code lässt sich nicht leicht an neue Features anpassen und fühlt sich daher an, als hätte er eine hohe Induktivität.
• Was die Aussage betrifft, dass „junk tech debt“ plötzlich ein AAA-Rating bekommt, scheint der Autor zu meinen, dass derselbe Code vor und nach dem Vendoring nicht plötzlich eine bessere Schuldenbewertung haben kann. Das betrachtet jedoch nur den Wert des Codes selbst und übersieht den wichtigsten Teil des gesamten Wertversprechens. Der Maintainer, der den Code vendort, besitzt ihn nun, und ein aktiver Maintainer, der Code aus einem toten Projekt übernimmt, steigert dessen Wert, weil es dann einen Menschen gibt, der auf Issues reagieren, Pull Requests prüfen und Bugs beheben kann.
• Dasselbe Muster wurde auch im JS-npm-Ökosystem beobachtet. Npm audit warnt meist übertrieben vor Sicherheitsproblemen, und sofern die Lizenz es erlaubt, ist dies einer der zuverlässigsten Wege, den lächerlichen Problemen zu entkommen, die man von Nutzern aufgebürdet bekommt.
• Es war ein Glücksfall, yaml-rust zu forken und als yaml-rust2 in reinem Rust neu zu schreiben. Dieser Fork besteht die YAML-Testsuite vollständig und zeigt in Benchmarks eine bessere Performance. Auch die Migration wirkt unkompliziert. Das Grundproblem bleibt jedoch bestehen: Wir verlassen uns weiterhin auf andere, die uns derzeit kostenlose Arbeit liefern, aber es gibt keine Garantie, dass sie das für immer tun werden.
• Wenn ein quellbasierter Paketmanager nicht das rechtliche Recht durchsetzt, dass eine Registry die Wartung veröffentlichter Pakete zwangsweise übernehmen darf, wird sie auf schreckliche Probleme stoßen: Vernachlässigung, böswillige Änderungen, böswillige Löschung, Identitätsvortäuschung und mehr. Für Pakete, die als wichtig genug für die Community gelten, braucht es eine Möglichkeit, den Registry-Eintrag dem ursprünglichen Besitzer zu entziehen und auf einen Fork umzuleiten.
• Wenn der Code funktioniert und das seit Jahren tut, warum sollte es dann wichtig sein, dass er nicht gewartet wird? Wenn man ihn nicht ändern muss und seine Grenzen und Fähigkeiten kennt, ist das kein Problem. Code wird nicht von selbst schlechter. Es war jahrzehntelang kein Problem, Code von vor vielen Jahren mehrfach zu übernehmen oder zu integrieren.
• Das Vendoring von Abhängigkeiten ist die Lösung. Das wurde seit 20 Jahren bei fast jeder Abhängigkeit gemacht, die „fertig“ ist und deren Entwicklung und Wartung sich verlangsamt hat.