Analyzing Dependency Distribution Changes Arising from Code Smell Interactions

Diese Studie analysiert an 116 Open-Source-Java-Systemen, wie Interaktionen zwischen Code-Smells die Verteilung statischer Abhängigkeiten verändern, und zeigt, dass solche Wechselwirkungen in den meisten Fällen zu einer signifikanten Zunahme der Abhängigkeiten führen, was für präzisere Detektions- und Refactoring-Strategien genutzt werden kann.

Das Wesentliche

🏗️ Der große Baustellen-Chaos-Check: Wenn schlechte Design-Entscheidungen sich gegenseitig anstecken

Stell dir vor, du hast ein riesiges, komplexes Haus gebaut – das ist dein Software-Programm. Damit das Haus stabil bleibt und man leicht ein Zimmer renovieren kann, ohne dass das ganze Dach einstürzt, muss es gut strukturiert sein. Jedes Zimmer (ein Modul) sollte seine eigenen Dinge erledigen und nicht ständig mit jedem anderen Zimmer verbunden sein.

Aber manchmal bauen Architekten (Programmierer) Fehler in den Plan. Diese Fehler nennt man „Code Smells" (wörtlich: „Code-Gestank"). Es sind keine riesigen Brände, sondern eher wie ein muffiger Geruch oder ein klemmendes Fenster. Ein Beispiel: Ein Zimmer, das so groß ist, dass es den ganzen Haushalt versorgen muss (ein „Gott-Klasse"-Fehler), oder ein Zimmer, das ständig in die Küche schaut, um Zutaten zu stehlen, statt selbst zu kochen (ein „Neid-Methoden"-Fehler).

Das Problem: Der „Gestank" ist ansteckend

Bisher haben Forscher meist nur untersucht, wie schlimm ein einzelner Gestank ist. Die große Frage dieser Studie war jedoch: Was passiert, wenn zwei oder mehr Gestänke sich treffen?

Die Forscher (Zhang, Wen und Tempero von der University of Auckland) haben sich 116 große, offene Software-Projekte (wie öffentliche Bauprojekte auf GitHub) angesehen. Sie haben sich gefragt: Wenn zwei „gestankige" Teile des Codes miteinander verbunden sind, wird das Chaos dann noch größer?

Stell dir das so vor:

• Einzelner Gestank: Ein Zimmer hat einen kaputten Wasserhahn. Das ist ärgerlich, aber man kann es reparieren, ohne das ganze Haus zu bewegen.
• Gestank-Interaktion: Der kaputte Wasserhahn (Fehler A) ist direkt mit einem undichten Fenster (Fehler B) verbunden. Wenn du den Hahn reparierst, reißt du das Fenster auf. Wenn du das Fenster dicht machst, bricht der Hahn ab. Die beiden Fehler verstärken sich gegenseitig.

Was haben die Forscher herausgefunden?

Die Studie hat zwei Hauptergebnisse geliefert, die wie eine Landkarte für Chaos-Vermeidung funktionieren:

1. Wenn sich Gestänke treffen, explodiert die Anzahl der Verbindungen.
Die Forscher haben gemessen, wie viele „Seile" (Abhängigkeiten) zwischen den Zimmern gespannt sind.

• Ergebnis: In den meisten Fällen (in 28 von 36 untersuchten Szenarien) führt das Zusammentreffen von zwei Gestänken zu einer massiven Zunahme der Seile.
• Die Analogie: Stell dir vor, du hast zwei Personen, die beide etwas falsch machen. Wenn sie sich unterhalten, verstricken sie sich in so viele Missverständnisse und Abhängigkeiten, dass sie kaum noch voneinander loskommen. Das macht das Haus (die Software) unflexibel und teuer zu reparieren.

2. Es gibt ein Muster im Chaos.
Das ist der spannende Teil. Nicht alle Verbindungen wachsen gleichmäßig. Es gibt ein vorhersehbares Muster:

• Manche Gestänke sind wie Vampire, die ständig Daten von anderen saugen (sie brauchen viele Verbindungen hin zu anderen).
• Andere sind wie Speicher, die nur Daten anbieten, aber nichts tun (sie haben viele Verbindungen von anderen zu ihnen).
• Wenn ein „Vampir" auf einen „Speicher" trifft, entstehen besonders viele Seile.
• Wenn zwei „Vampire" sich treffen, versuchen sie oft, sich gegenseitig zu füttern, was auch zu vielen Seilen führt.

Die Forscher haben eine Art „Gestank-Typologie" erstellt. Sie können jetzt vorhersagen: „Wenn du einen 'Gott-Klassen'-Fehler hast, der mit einem 'Daten-Klassen'-Fehler interagiert, dann wirst du garantiert eine Flut von Verbindungen sehen, die du so nicht erwartet hättest."

Warum ist das wichtig für dich? (Die praktische Anwendung)

Stell dir vor, du bist der Hausmeister dieses riesigen Gebäudes. Früher hast du gesagt: „Okay, ich repariere alle kaputten Fenster einzeln." Das war ineffizient.

Mit den Erkenntnissen dieser Studie kannst du jetzt klüger vorgehen:

1. Priorisieren: Wenn du zwei Fehler siehst, die sich gegenseitig „anstecken" (also viele Seile zwischen ihnen haben), repariere diese zuerst. Das bringt den größten Gewinn. Ein einzelner Fehler ist oft harmlos; ein paar verbundener Fehler sind eine Katastrophe.
2. Bessere Reparaturpläne: Wenn du weißt, dass ein „Vampir"-Fehler auf einen „Speicher"-Fehler trifft, weißt du genau, wie du sie trennen musst. Vielleicht musst du das „Vampir"-Zimmer direkt in das „Speicher"-Zimmer einbauen, damit sie nicht mehr durch Seile verbunden sein müssen.
3. Früherkennung: Wenn du siehst, dass ein Zimmer plötzlich extrem viele Seile zu einem anderen hat, kannst du fast sicher sein: „Aha! Da versteckt sich ein Gestank!" Du musst nicht warten, bis das Haus brennt, sondern kannst es vorher erkennen.

Fazit in einem Satz

Die Studie zeigt uns, dass Software-Fehler nicht isoliert betrachtet werden dürfen. Wenn sie sich treffen, verstricken sie sich in ein Netz aus Verbindungen, das das System unflexibel macht. Wer versteht, wie diese Fehler interagieren, kann Software nicht nur reparieren, sondern sie zukunftssicher und leicht wartbar machen.

Kurz gesagt: Ein einzelner Gestank ist lästig. Ein Paar, das sich gegenseitig ansteckt, ist ein Albtraum. Aber wenn du weißt, wie sie sich anstecken, kannst du den Albtraum verhindern.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „Analyzing Dependency Distribution Changes Arising from Code Smell Interactions" auf Deutsch:

1. Problemstellung

Die Modularität ist ein entscheidender Faktor für die Wartbarkeit von Software. Zu viele Abhängigkeiten zwischen Modulen können bei Änderungen zu „Ripple-Effekten" (Kaskadeneffekten) führen, was Wartungsaufgaben komplex und kostspielig macht. Ein zentrales, aber noch wenig erforschtes Problem ist der Einfluss von Code Smells (Indikatoren für Designmängel) auf diese Abhängigkeiten.

Während einzelne Code Smells oft nur geringe Auswirkungen auf die Wartbarkeit haben, deuten Studien darauf hin, dass das Zusammentreffen (Interaktion) mehrerer Smells die Situation drastisch verschlimmern kann. Bisherige Forschung hat sich meist auf das gleichzeitige Vorkommen (Co-occurrence) innerhalb derselben Klasse konzentriert. Es fehlt jedoch an empirischen Belegen dafür, wie sich statische Abhängigkeiten (z. B. Methodenaufrufe, Datennutzung) ändern, wenn Code Smells über diese Abhängigkeiten miteinander interagieren, auch über Klassengrenzen hinweg. Die Autoren untersuchen, ob und wie die Verteilung dieser Abhängigkeiten durch solche Interaktionen beeinflusst wird.

2. Methodik

Die Studie basiert auf einer groß angelegten empirischen Analyse von 116 Open-Source-Java-Systemen (ausgewählt nach Sternen auf GitHub, mit Fokus auf aktive, reine Java-Projekte).

• Untersuchte Code Smells: Die Autoren fokussieren sich auf fünf weit verbreitete Smells:
  • Feature Envy (FE): Eine Methode, die mehr Daten einer anderen Klasse nutzt als ihrer eigenen.
  • Brain Method (BM): Eine übermäßig große und komplexe Methode.
  • God Class (GC): Eine Klasse, die zu viele Verantwortlichkeiten bündelt.
  • Brain Class (BC): Eine extrem große Klasse, die oft eine BM enthält.
  • Data Class (DC): Eine Klasse, die nur Daten hält und wenig Verhalten kapselt.
• Definition von Interaktion: Zwei Artefakte (z. B. Klassen, Methoden) interagieren, wenn eine statische Abhängigkeit zwischen ihnen besteht. Die Autoren unterscheiden zwischen Interaktionen innerhalb derselben Klasse (Same) und zwischen verschiedenen Klassen (Different).
• Datenanalyse:
  • Es wurden alle statischen Abhängigkeitstypen (z. B. call, create, use, parameter, extend) zwischen den Artefakten extrahiert (unter Verwendung von CodeQL).
  • Für jedes Paar von Smell-Typen (z. B. GC und DC) wurden drei Szenarien verglichen:
    1. CS1-CS2: Beide Artefakte haben Smells.
    2. CS1-nonCS2: Nur das erste Artefakt hat einen Smell.
    3. nonCS1-CS2: Nur das zweite Artefakt hat einen Smell.
  • Statistische Tests: Es wurden nicht-parametrische Tests (Mann-Whitney-U-Test) durchgeführt, um signifikante Unterschiede in der Anzahl der Abhängigkeiten zu ermitteln. Als Effektgröße wurde Cliff's Delta ($\delta$) verwendet, um die Richtung (Zunahme oder Abnahme) und die Stärke der Veränderung zu quantifizieren.
  • Die Analyse erfolgte sowohl aggregiert über alle Systeme (Union-Dataset) als auch pro individuellem System.

3. Wichtige Beiträge

1. Erste groß angelegte empirische Evidenz: Der Nachweis, dass Interaktionen zwischen Code Smells signifikant mit einer Zunahme der Gesamtzahl der statischen Abhängigkeiten verbunden sind.
2. Konsistente Richtungsänderungen: Die Entdeckung, dass bestimmte Smell-Kombinationen konsistente Muster in der Veränderung spezifischer Abhängigkeitstypen (z. B. Datenzugriffe, Methodenaufrufe) aufweisen.
3. Typologie der Smells: Entwicklung einer multidimensionalen Typologie, die Smells basierend auf ihrer Rolle als „Provider" (Anbieter) oder „Consumer" (Verbraucher) von Daten und Funktionalität klassifiziert (stark vs. schwach).
4. Praktische Leitlinien: Ableitung konkreter Strategien für die Priorisierung von Refactoring-Maßnahmen und die Verbesserung von Smell-Erkennungswerkzeugen.
5. Reproduzierbarkeit: Bereitstellung eines vollständigen Replication Packages mit allen Daten, Detektions-Queries und Analyse-Skripten.

4. Ergebnisse

• Häufigkeit von Interaktionen (RQ1): Code Smells interagieren sehr häufig. Über 50 % der untersuchten Smell-Paare weisen eine Interaktionshäufigkeit von über 40 % auf. Besonders hoch ist die Interaktion zwischen Brain Class und Brain Method (99,7 %), da eine BC per Definition eine BM enthält.
• Auswirkung auf Abhängigkeiten (RQ2):
  • Gesamtzahl: In 28 von 36 untersuchten Fällen führen Interaktionen zu einer signifikanten Zunahme der Gesamtzahl der Abhängigkeiten.
  • Spezifische Abhängigkeitstypen: Die signifikantesten Veränderungen treten bei Datenzugriffs-Abhängigkeiten (z. B. use, call auf Accessors) und Methodenaufrufen (call zwischen Functional Methods) auf.
  • Konsistenz: Für eine gegebene relative Position (in derselben vs. in verschiedenen Klassen) und Rolle (Provider/Consumer) zeigen die meisten Smells eine konsistente Richtung der Veränderung.
    • Beispiel: Ein Feature Envy (starker Daten-Consumer) führt bei Interaktion mit einer Data Class (starker Daten-Provider) zu einer Zunahme von Datenzugriffs-Abhängigkeiten.
    • Beispiel: Brain Methods sind schwache Anbieter von Funktionalität; Interaktionen mit ihnen führen oft zu einer Abnahme von Methodenaufrufen.
• Systemübergreifende Konsistenz: Obwohl die Effektstärken zwischen den Projekten variieren, bleibt die Richtung der Veränderung (Zunahme oder Abnahme) in den meisten Projekten konsistent mit dem aggregierten Trend.

5. Bedeutung und Implikationen

Die Ergebnisse haben weitreichende Konsequenzen für Software-Engineering und Wartung:

• Priorisierung von Refactoring: Entwickler sollten Interaktionen zwischen Smells priorisieren, da diese komplexere Abhängigkeitsstrukturen erzeugen und Fehleranfälliger sind als isolierte Smells. Das Beheben einer interagierenden Paarung kann mehrere Probleme gleichzeitig lösen und Ripple-Effekte reduzieren.
• Verbesserte Detektion: Die Typologie kann genutzt werden, um die Detektion von Smells zu verbessern. Wenn ein Smell (z. B. GC) bestätigt ist, kann die Analyse der Abhängigkeitsmuster zu benachbarten Artefakten Hinweise darauf geben, ob diese ebenfalls Smells aufweisen (z. B. wenn eine GC wenig Methodenaufrufe zu einer Methode macht, könnte diese Methode ein Feature Envy sein).
• Strategische Refactoring-Ansätze:
  • Bei Interaktionen zwischen Feature Envy und Data Class wird empfohlen, die Methode in die Data Class zu verschieben, um die Datenkapselung zu stärken.
  • Bei Interaktionen zwischen God Class und Brain Class sollte nicht nur getrennt refaktoriert werden, sondern gemeinsam eine neue, fokussierte Klasse extrahiert werden, um die verflochtenen Verantwortlichkeiten zu trennen.
• Theoretischer Beitrag: Die Studie liefert ein quantitatives Fundament für das Verständnis, wie Designmängel die Modularität durch statische Kopplung degradieren, und geht über qualitative Beobachtungen hinaus.

Zusammenfassend zeigt das Paper, dass Code Smells nicht isoliert betrachtet werden dürfen; ihre Interaktionen sind ein kritischer Treiber für wachsende Komplexität und Abhängigkeiten, deren Verständnis essenziell für effektive Software-Wartung ist.