Analyzing Dependency Distribution Changes Arising from Code Smell Interactions

Deze studie analyseert 116 open-source Java-systemen en concludeert dat interacties tussen codegeuren vaak leiden tot een significante toename van statische afhankelijkheden, wat nuttige inzichten biedt voor het verbeteren van detectie, prioritering en refactoringstrategieën.

De kern

Stel je voor dat software een enorme, levende stad is. Elke gebouwen (de modules) hebben wegen die ze met elkaar verbinden. Als je een klein raam in één gebouw vervangt, kan dat soms leiden tot een reeks onverwachte gevolgen in de hele stad: verkeer stopt, leidingen breken, en buren klagen. In de programmeertaal noemen we deze "wegen" afhankelijkheden. Hoe meer wegen er zijn, hoe moeilijker en duurder het is om de stad te onderhouden.

De onderzoekers van dit paper (Zhang, Wen en Tempero) hebben zich afgevraagd: Wat zorgt ervoor dat er steeds meer wegen worden aangelegd?

Ze kijken niet naar de gebouwen zelf, maar naar de "geur" van de straten. In de programmeerwereld noemen we slechte ontwerpen code smells (letterlijk: code-stank). Het zijn geen fouten die de software laten crashen, maar ze voelen "raar" aan, zoals een gebouw dat te veel kamers heeft of een kamer die te veel werk doet.

Het Grote Geheim: De "Stank-Interactie"

Tot nu toe hebben onderzoekers vooral gekeken naar één soort stank op zichzelf. Maar de onderzoekers ontdekten iets interessants: Stank is er zelden alleen.

Stel je voor:

• God Class: Een gebouw dat zo groot is dat het de hele stad bestuurt.
• Feature Envy: Een kamer die jaloers is op de meubels van de buren en daar constant heen kijkt.
• Data Class: Een gebouw dat alleen maar dozen met spullen bevat, maar zelf niets doet.

Als je alleen een "God Class" hebt, is het al lastig. Maar wat gebeurt er als die "God Class" jaloers is op de "Data Class"? Of als een "Brain Method" (een kamer die te veel denkt) samenwerkt met een "Feature Envy"?

De onderzoekers hebben 116 grote, openbare softwaresteden (Java-projecten) onder de loep genomen. Ze zochten naar momenten waar deze "stank-gebouwen" met elkaar in contact kwamen via de wegen (afhankelijkheden).

Wat vonden ze? (De Simpele Vertaling)

1. Stank trekt stank aan (en maakt de wegen dichter)
Ze ontdekten dat wanneer twee soorten "stank" met elkaar interageren, er veel meer wegen worden aangelegd tussen de gebouwen.

• Analogie: Als een jaloerse burenman (Feature Envy) constant contact zoekt met een voorraadkast (Data Class), bouwen ze een tunnel, een telefoonlijn, een brievenbus en een lift. Het wordt een wirwar van verbindingen.
• Conclusie: Interacties tussen slechte ontwerpen zorgen voor een explosie aan complexiteit. Het is niet alleen "een beetje" slechter, het is veel, veel erger.

2. Het patroon is voorspelbaar
Niet alleen werden er meer wegen aangelegd, maar ze deden dit op een heel specifiek, voorspelbaar patroon.

• Sommige "stank-gebouwen" zijn altijd de gevers (ze geven data).
• Andere zijn altijd de nemers (ze vragen data).
• Als een "Nemer" (zoals Feature Envy) contact zoekt met een "Gever" (zoals Data Class), ontstaan er specifieke soorten wegen (zoals directe lijnen naar de voorraadkast).
• De onderzoekers hebben een soort "stank-kaart" gemaakt die voorspelt: "Als je deze twee soorten stank bij elkaar ziet, dan zullen ze waarschijnlijk op deze manier met elkaar verbonden zijn."

3. Waarom is dit belangrijk voor jou?
Stel je voor dat je een stadsherstelproject hebt. Je hebt niet genoeg geld om alle gebouwen te renoveren. Waar begin je?

• Vroeger: Je zou kijken naar het grootste gebouw of het oudste gebouw.
• Nu: Je kijkt naar de interacties. Als je twee gebouwen ziet die "stank" hebben en die met elkaar verbonden zijn, moet je die eerst aanpakken.
• Waarom? Omdat het oplossen van die interactie niet alleen één probleem oplost, maar een hele bundel van verkeerde wegen tegelijk weghaalt. Het is alsof je een verkeersknooppunt oplost in plaats van alleen een stoplicht.

De Praktische Tips (De "Gouden Raad")

De onderzoekers geven drie concrete adviezen aan programmeurs en managers:

1. Prioriteit geven: Pak niet zomaar een "stank" aan. Zoek naar de paren die met elkaar praten. Die zijn het gevaarlijkst voor de stabiliteit van je software.
2. Slimmer renoveren: Als je een "jaloerse kamer" (Feature Envy) ziet die constant naar een "voorraadkast" (Data Class) kijkt, verplaats die kamer dan naar het gebouw van de voorraadkast. Dan hoef je geen wegen meer te bouwen; de kamer zit er gewoon in. De software wordt dan schoner en simpeler.
3. Betere detectie: Software-tools die op zoek gaan naar fouten, kunnen nu slimmer worden. Als ze zien dat een gebouw veel contact heeft met een "voorraadkast", kunnen ze waarschuwingslichten aantonen dat er waarschijnlijk een "jaloerse kamer" schuilgaat, zelfs als ze die nog niet direct hebben gezien.

Samenvattend

Deze studie zegt eigenlijk: "Slechte ontwerpen zijn gevaarlijker als ze met elkaar bevriend zijn."

Het is alsof je een huis hebt met één lekkende kraan. Dat is vervelend. Maar als die kraan lekt en tegelijkertijd de vloerbedekking nat maakt en de muren beschadigt, dan heb je een ramp. De onderzoekers hebben bewezen dat deze "rampen" (interacties) zorgen voor een enorme toename aan complexiteit. Door deze interacties te herkennen en op te lossen, kunnen we software veel makkelijker, goedkoper en veiliger houden.

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het paper "Analyzing Dependency Distribution Changes Arising from Code Smell Interactions" in het Nederlands.

Probleemstelling

Softwareonderhoud wordt complex en kostbaar wanneer modules te sterk van elkaar afhankelijk zijn. Veranderingen in één module kunnen dan "golf-effecten" (ripple effects) veroorzaken door de hele codebase. Hoewel het bekend is dat code smells (symptomen van designproblemen) de kwaliteit van code verminderen, is de impact van hun interactie onderbelicht.

Bestaand onderzoek toont vaak aan dat geïsoleerde code smells geen significant negatief effect hebben op onderhoudbaarheid, terwijl meerdere smells die samen voorkomen (co-locatie) of via statische afhankelijkheden met elkaar verbonden zijn, wel grote problemen veroorzaken. Er is echter weinig empirisch bewijs over hoe deze interacties de distributie en het aantal statische afhankelijkheden beïnvloeden. Dit paper onderzoekt of en hoe de aanwezigheid van code smell-interacties leidt tot veranderingen in het aantal en de aard van deze afhankelijkheden.

Methodologie

De auteurs hebben een grote empirische studie uitgevoerd met de volgende kenmerken:

• Dataset: 116 populaire, open-source Java-systemen van GitHub (geselecteerd op basis van sterren en forks, met >80% Java-code).
• Onderzochte Code Smells: Vijf veelvoorkomende smells, gedefinieerd volgens de metrische aanpak van Lanza en Marinescu:
  1. Feature Envy (FE): Een methode die meer afhankelijk is van data uit een andere klasse dan van eigen data.
  2. Brain Method (BM): Een te grote, complexe methode.
  3. God Class (GC): Een klasse die te veel functionaliteit centraliseert.
  4. Brain Class (BC): Een zeer grote klasse met lage coherentie.
  5. Data Class (DC): Een klasse die voornamelijk data vasthoudt zonder gedrag.
• Definitie van Interactie: Twee artefacten (bijv. methoden, klassen) interageren als er een statische afhankelijkheid (zoals een aanroep, instantiatie of veldtoegang) tussen hen bestaat.
• Data-analyse:
  • De auteurs hebben alle afhankelijkheden geëxtraheerd met CodeQL.
  • Ze hebben de afhankelijkheidsdistributie vergeleken tussen situaties met interactie (bijv. GC-FE) en situaties zonder interactie (bijv. GC-nonFE).
  • Er zijn vier vergelijkingen gemaakt per paar smells, rekening houdend met de relatieve locatie (zelfde klasse vs. verschillende klassen).
  • Statistische tests: De Mann-Whitney U test werd gebruikt voor significantie (vanwege niet-normale verdeling) en Cliff's Delta voor het effectgrootte (richting en sterkte van de verandering).
  • Correctie: De Benjamini-Hochberg procedure werd toegepast om het risico op valse ontdekkingen bij multiple testing te minimaliseren.

Belangrijkste Bijdragen

1. Grootschalig Empirisch Bewijs: Dit is de eerste studie die kwantitatief aantoont dat code smell-interacties correleren met een significant toename in het totale aantal statische afhankelijkheden.
2. Gedetailleerde Typologie: De auteurs presenteren een multidimensionale typologie die voorspelt of een specifieke smell als "sterk" (verhoogt afhankelijkheden) of "zwak" (verlaagt afhankelijkheden) fungeert in zijn rol als provider of consumer van data of functionaliteit.
3. Open Data: Alle broncode, detectie-output, metrische data en statistische resultaten zijn openbaar beschikbaar in een replicatiepakket.

Resultaten

De analyse leverde de volgende kernbevindingen op:

• Frequentie van Interactie: Code smells interageren zeer frequent. Ongeveer 50% van de smell-paren heeft een interactiefrequentie van meer dan 40%. Bijvoorbeeld, 99,7% van de Brain Classes interageert met Brain Methods.
• Toename van Afhankelijkheden (RQ2):
  • In 28 van de 36 onderzochte gevallen leidde de interactie tussen smells tot een significant toename in het totale aantal afhankelijkheden.
  • Dit effect is het sterkst bij afhankelijkheden tussen klassen (verschillende locaties) en zwakker binnen dezelfde klasse.
• Specifieke Afhankelijkheidstypen:
  • De grootste verschillen werden gevonden bij data-toegang (bijv. use, call naar accessors) en functional method calls (call tussen methoden).
  • Deze specifieke afhankelijkheidstypen vertonen een consistente veranderingsrichting (ofwel altijd toename, ofwel altijd afname) wanneer een specifieke smell met een andere smell interageert.
  • Voorbeeld: Een Feature Envy (sterke data-consumer) in combinatie met een Data Class (sterke data-provider) leidt tot een toename in data-toegang-afhankelijkheden.
• Consistentie per Project: Hoewel de grootte van het effect varieert per project, volgt de richting van de verandering (toename/afname) in de meeste projecten de algemene trend die in de totale dataset werd gevonden.

Betekenis en Praktische Implicaties

De bevindingen hebben directe gevolgen voor software-engineering en tooling:

1. Prioritering van Refactoring: Ontwikkelaars moeten eerst geïsoleerde code smells oplossen die met elkaar interageren. Deze interacties creëren dichte, complexe afhankelijkheidsnetwerken die onderhoud moeilijker maken en foutgevoeliger zijn. Het oplossen van een interactiepaar kan een groter aantal "randen" in het afhankelijkheidsgraph elimineren dan het oplossen van een enkele smell.
2. Verbeterde Detectie: De typologie kan worden gebruikt om de detectie van code smells te verbeteren. Als een artefact een bekende smell vertoont, kan de richting en het aantal afhankelijkheden naar een ander artefact worden gebruikt als bewijs om te voorspellen of dat andere artefact ook een specifieke smell vertoont (bijv. lage aanroepen van een God Class naar een methode suggereren dat die methode Feature Envy is).
3. Gerichte Refactoring-strategieën: De studie biedt concrete richtlijnen.
   • Voorbeeld: Als een Feature Envy (FE) veel data van een Data Class (DC) gebruikt, is de beste strategie vaak het verplaatsen van de FE-methode naar de DC. Dit vermindert externe data-toegang en maakt de DC rijker aan gedrag.
   • Voorbeeld: Bij interacties tussen God Classes en Brain Classes, kan het beter zijn om een gedeelde klasse te extraheren die de verweven verantwoordelijkheden oplost, in plaats van ze los van elkaar te splitsen.
4. Tool Ontwikkeling: Tools voor onderhoud en refactoringsuggesties kunnen deze patronen gebruiken om niet alleen te waarschuwen voor smells, maar ook om de risico's van verandering (ripple effects) beter te kwantificeren.

Kortom, dit paper beweert dat de interactie tussen code smells een cruciale factor is in de degradatie van softwarekwaliteit, en dat het begrijpen van de daaruit voortvloeiende afhankelijkheidsdistributie essentieel is voor effectief softwarebeheer.