CLEM: A Behavior-Centric Software Quality Measurement Framework for Structural Change Monitoring

Stellen Sie sich vor, Sie beobachten das Wachstum einer Stadt. Sie könnten zählen, wie viele Ziegelsteine pro Tag verlegt werden, oder Sie könnten prüfen, ob der Stadtrat die Regeln eingehalten hat. Aber es gibt einen dritten, interessanteren Weg, eine Stadt zu betrachten: Beobachten Sie, wie sich die Gebäude verändern. Reißen die Menschen alte Wände ein, um ein neues Zimmer hinzuzufügen? Bauen sie einen neuen Flügel an, der an die Seite anschließt, ohne das Haupthaus zu berühren? Ändern sie einfach nur einen Schalter, um die Beleuchtung zu verändern? Oder stellen sie lediglich die Möbel um? In der Welt der Softwareentwicklung ist dies genau die Frage, die Forscher stellen. Software ist nicht nur Code; sie ist ein lebendiges System, das sich ständig verändern muss, um nützlich zu bleiben. Wenn ein System nur dadurch wächst, dass es seine eigenen Wände einreißt, wird es schließlich zu einem wackeligen, gefährlichen Chaos. Aber wenn es sich dadurch verändert, dass neue Flügel hinzugefügt oder Schalter umgelegt werden, bleibt es stark und flexibel. Dies ist der Kern der „Softwarequalität“ – nicht nur, ob der Code heute funktioniert, sondern ob er morgen weiterwachsen kann, ohne auseinanderzufallen.

Dieses Paper stellt ein neues Werkzeug namens CLEM (Change Localization and Externalization Measurement) vor, um genau diese Frage zu beantworten. Anstatt nur zu zählen, wie viel Code geändert wurde, agiert CLEM wie ein Detektiv, der beobachtet, wie Entwickler ein System reparieren oder aktualisieren. Es sortiert jede Änderung in eines von vier „Personas“ ein:

1. Modification (M) [Modifikation]: Der „Wände-einreißen“-Ansatz. Den Kerncode direkt verändern. Es ist schnell, aber riskant, wie das Hineinhacken eines Lochs in eine Wand, um eine Tür einzubauen.
2. Extension (E) [Erweiterung]: Der „Anbau“-Ansatz. Neue Funktionen bauen, die sich in das System einfügen, ohne das Kernstück zu berühren, wie das Anbauen eines neuen Zimmers an ein Haus.
3. Low-code (L): Der „Flussdiagramm“-Ansatz. Visuelle Tools oder Regeln nutzen, um das Verhalten zu ändern, wie ein Manager, der einen Arbeitsablauf umstellt, ohne Code zu schreiben.
4. Configuration (C) [Konfiguration]: Der „Schalter“-Ansatz. Nur Einstellungen oder Parameter ändern, wie das Drehen an einem Regler, um die Lautstärke zu ändern.

Die Forscher haben diese Idee bei drei verschiedenen Softwareprojekten getestet: zwei öffentlichen Projekten aus einem großen Technologie-Ökosystem und einer privaten Gesundheits-App. Sie fanden heraus, dass CLEM klar zwischen einem System, das „gesund“ ist (hauptsächlich durch Anbauten und Schalter wachsend), und einem, das „krank“ ist (ständig den eigenen Kern hackend), unterscheiden kann. Sie entdeckten jedoch auch etwas Überraschendes: Zu wissen, wie sich ein System verändert, sagt nicht automatisch voraus, ob es im nächsten Monat mehr Bugs haben wird. Es ist ein großartiges Werkzeug, um die Struktur eines Systems zu verstehen, aber es ist keine Kristallkugel zur Vorhersage zukünftiger Fehler.

Das neue Notizbuch des Detektivs: Wie CLEM funktioniert

Stellen Sie sich die Softwareentwicklung wie eine geschäftige Küche vor. Jahrelang wurden Köche (Entwickler) danach gemessen, wie viele Gerichte sie kochen (Aktivitätsvolumen) oder wie sauber die Küche am Ende des Abends ist (statische Code-Prüfungen). Aber was, wenn die Küche auseinanderfällt, weil sie jedes Mal eine Wand einreißen müssen, wenn sie ein neues Gewürz brauchen? Das ist das Problem, das CLEM löst. Es zählt nicht nur die Gerichte; es beobachtet die Methode, mit der die Köche an die Zutaten gelangen.

Das Paper schlägt vor, dass jede Aktualisierung eines Softwaresystems auf eine von vier Arten erfolgt und dass die Mischung dieser Arten alles über die Gesundheit des Systems aussagt.

• Modification (M) ist die „Brute-Force“-Methode. Es ist, als würde ein Koch einen Vorschlaghammer benutzen, um eine Wand einzuschlagen, weil er ein neues Regal braucht. Es erledigt den Job schnell, aber wenn man das zu oft macht, wird das gesamte Gebäude instabil.
• Extension (E) ist die „modulare“ Methode. Es ist, als würde man einen neuen, abtrennbaren Wagen bauen, der in die Küche rollt. Der Koch berührt die Wände nicht; er fügt einfach ein neues Werkzeug hinzu. Dies ist sicherer und hält die Kernstruktur intakt.
• Low-code (L) ist die „Blueprint“-Methode. Stellen Sie sich einen Manager vor, der einen neuen Ablauf auf ein Whiteboard zeichnet, der den Robotern sagt, was sie tun sollen, ohne dass die Roboter umprogrammiert werden müssen. Es ist eine höherwertige Art, Dinge zu ändern.
• Configuration (C) ist die „Regler“-Methode. Es ist nur das Drehen eines Knopfes, um den Ofen heißer oder das Licht heller zu machen. Gar keine Konstruktion nötig.

Die Autoren argumentieren, dass ein gesundes, langlebiges Softwaresystem sich eher auf Extension, Low-code und Configuration verlassen sollte und weniger auf Modification. Wenn ein System ständig seinen Kern „modifiziert“, häuft es wahrscheinlich „Technical Debt“ an – ein schicker Begriff dafür, dass es Stabilität aus der Zukunft leiht und diese später mit Zinsen zurückzahlen muss.

Das Experiment: Drei Küchen beobachten

Um zu sehen, ob diese Idee funktioniert, unternahmen die Forscher einen Ausflug zu drei verschiedenen „Küchen“ (Software-Repositories). Sie sahen sich nicht nur die fertigen Gerichte an; sie beobachteten die Hände der Köche über Monate hinweg.

1. Die „Fit“-Küche (fit-framework): Dies war ein öffentliches Projekt, das als Plugin-System konzipiert wurde. Sie erwarteten es voll von „Extensions“ (E) zu sein.
2. Die „App“-Küche (app-platform): Dies war ein weiteres öffentliches Projekt, aber es wurde für visuelles Low-Code-Design gebaut. Sie erwarteten es voll von „Low-code“ (L) und „Configuration“ (C) zu sehen.
3. Die „Antisuger“-Küche: Dies war eine private Gesundheits-App zur Verwaltung des Blutzuckers. Sie wurde von einem anderen Team mit anderen Werkzeugen entwickelt. Sie erwarteten, dass sie sich in einer frühen, chaotischen Phase befindet, wahrscheinlich voller „Modifications“ (M).

Die Forscher analysierten 607 spezifische Updates (Commits) über diese Projekte hinweg. Sie nutzten einen Satz transparenter Regeln, um die geänderten Dateien zu untersuchen. Wenn eine Datei in einem „Plugin“-Ordner lag, zählten sie sie als Extension. Wenn es eine „Flow“-Datei war, zählten sie sie als Low-code. Wenn es eine Kern-Code-Datei war, war es eine Modification.

Was sie fanden: Die Systeme sahen unterschiedlich aus

Die Ergebnisse entsprachen genau der Theorie der „gesunden Küche“.

• Die App-platform war in der Tat sehr „externalisiert“. Etwa 69,5 % ihrer Änderungen waren Extensions, mit sehr wenig direktem Hacking des Kerns. Ihr „CLEM-ES“-Score (ein Maß dafür, wie viel der Änderung vom Kern weg verlagert wurde) war ein starkes +0,685.
• Das Fit-framework war eine Mischung. Es hatte viele Extensions (33,4 %), aber auch einen signifikanten Anteil an Modifications (29,1 %). Sein Score war +0,418, was zeigt, dass es gesünder als ein reines Chaos war, aber nicht so „externalisiert“ wie die App-platform.
• Die Antisuger Gesundheits-App war das Gegenteil. Sie war fast vollständig „Modification“-dominant, wobei 83,0 % ihrer Änderungen direkte Kern-Edits waren. Ihr Score war -0,659, was darauf hindeutet, dass sie sich noch in einer fragilen „Wände-hacken“-Phase befand.

Dies bewies, dass CLEM erfolgreich den Unterschied zwischen einem System, das durch das Hinzufügen von Flügeln wächst, und einem, das durch das Einschlagen von Wänden wächst, erkennen kann. Die Forscher prüften sogar die Fairness ihrer Regeln, indem sie zwei Menschen die 160 zufälligen Updates prüfen ließen. Diese stimmten zu 100 % in der Hauptkategorie überein, was darauf hindeutet, dass die Regeln solide und reproduzierbar sind.

Die Wendung: Struktur sagt Bugs nicht voraus (noch nicht)

Hier wird das Paper sehr vorsichtig. Man könnte denken: „Wenn ein System seine eigenen Wände hackt (hohe Modification), sollte es öfter kaputtgehen, richtig?“ Die Forscher testeten dies. Sie untersuchten, ob die CLEM-Scores vorhersagen konnten, ob das System im folgenden Monat mehr „Bugfixes“ haben würde.

Die Antwort? Kein klarer Zusammenhang.
In ihrem Datensatz korrelierte der „Modification“-Score nicht zuverlässig damit, ob der nächste Monat voll von Bugfixes sein würde. Der „CLEM-ES“-Score (wie externalisiert die Änderungen waren) hatte in dieser spezifischen Stichprobe fast null Korrelation mit zukünftigen Bugfixes.

Dies ist ein entscheidender Befund. Die Autoren betonen ausdrücklich, dass CLEM keine magische Kristallkugel zur Vorhersage von Defekten ist. Es ersetzt nicht die alten Wege des Zählens von Bugs oder Code-Churn. Stattdessen bietet es eine andere Art von Erkenntnis. Es sagt Ihnen etwas über die strukturelle Haltung des Systems. Ein System mit einem hohen Modification-Score hat vielleicht heute nicht mehr Bugs, aber es baut eine Struktur auf, die schwerer zu warten ist und mit der Zeit wahrscheinlicher fragil wird. Es ist wie ein Gebäude, das statisch unsicher ist; es mag heute nicht einstürzen, aber der Bauplan ist schlecht.

Warum das wichtig ist

Das Paper kommt zu dem Schluss, dass CLEM eine leistungsstarke neue Linse für Software-Manager ist. Es verschiebt die Diskussion von „Wie viel Code haben wir geschrieben?“ zu „Wie verändern wir unser System?“.

• Wenn Sie sehen, dass ein Team ständig Modifications durchführt, ist das ein Signal, innezuhalten und zu fragen: „Warum reißen wir unsere eigenen Wände ein? Können wir stattdessen ein Plugin bauen?“
• Wenn Sie sehen, dass ein Team hauptsächlich Extensions und Configurations nutzt, deutet dies darauf hin, dass das System reift und stabiler wird.

Die Autoren sind ehrlich über die Grenzen ihrer Arbeit. Sie geben zu, dass ihre Stichprobengröße klein war (nur wenige Monate Daten aus drei Projekten) und dass der Teil der „Bug-Vorhersage“ nicht wie erhofft funktionierte. Sie schlagen vor, dass CLEM am besten als komplementäres Werkzeug verwendet werden sollte – als eine Möglichkeit, die strukturelle Gesundheit eines Systems neben traditionellen Metriken im Auge zu behalten. Es ist kein endgültiges Urteil über die Qualität, aber ein sehr klarer, prüfbarer Weg, um zu sehen, ob ein Softwaresystem lernt, erwachsen zu werden, oder ob es in der Gewohnheit stecken bleibt, sein eigenes Fundament zu zertrümmern.

Kurz gesagt: CLEM gibt uns eine Vokabel, um über die Form der Veränderung zu sprechen. Es hilft uns zu sehen, ob unsere Software einen Wolkenkratzer baut oder nur Ziegel auf einen wackeligen Stapel schichtet – und dieser Unterschied könnte das Wichtigste sein, das wir für das langfristige Überleben eines jeden digitalen Systems messen können.