A Concern-Centric Empirical Evaluation of Multi-Language Code Smells: An LLM-Assisted Study of JNI Software Evolution
Dit artikel presenteert een op zorgen gerichte empirische evaluatie van JNI-codegeuren met behulp van LLM-ondersteunde analyse van 8.207 commits over 15 open-source projecten, waarbij wordt onthuld dat bestaande geurdefinities slechts 36,5% van de onderhoudsgerelateerde zorgen van ontwikkelaars dekken en drie nieuwe geurdefinities worden voorgesteld om de geïdentificeerde hiaten aan te pakken.
Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer
Moderne software voelt vaak aan als een goed geoliede machine, maar onder de gestroomlijnde interface is het vaak opgebouwd uit vele verschillende onderdelen die verschillende talen spreken. Om een programma snel, efficiënt of in staat te stellen om met gespecialiseerde hardware te communiceren, combineren ontwikkelaars vaak code geschreven in de ene taal met code geschreven in een andere. Een veelvoorkomende manier om dit te doen is via een brug genaamd de Java Native Interface, die een programma geschreven in Java in staat stelt om uit te reiken en krachtige tools geschreven in C of C++ te gebruiken. Hoewel deze mix van talen software grote kracht geeft, creëert het ook een uniek soort puinhoop. Net zoals een vertaler moeite kan hebben om twee verschillende dialecten consistent te houden, kan de software verborgen gebreken ontwikkelen waarbij de twee talen er niet over eens worden hoe ze gegevens moeten delen, geheugen moeten beheren of fouten moeten afhandelen. Deze gebreken, in de industrie bekend als "code smells", zijn geen bugs die het programma onmiddellijk laten crashen, maar eerder ontwerpkeuzes die de software moeilijk maken om te repareren, bij te werken of te begrijpen in de loop van de tijd. Jarenlang hebben experts geprobeerd deze smells te catalogiseren door lijsten te maken van hoe slecht cross-language design eruit ziet. Maar een kritische vraag bleef onbeantwoord: komen deze lijsten daadwerkelijk overeen met de echte problemen waar ontwikkelaars dagelijks mee te maken krijgen wanneer zij proberen deze complexe systemen draaiende te houden?
Een team van onderzoekers zette zich schouder aan schouder in om deze vraag te beantwoorden door direct naar de geschiedenis te kijken van hoe software in de loop van de tijd verandert, in plaats van alleen maar naar de code zelf te staren. Ze richtten zich op vijftien populaire open-source projecten die zwaar leunen op deze Java-naar-C brug. In plaats van te gokken wat er mis zou kunnen zijn, onderzochten ze duizenden updates, of "commits", die ontwikkelaars door de jaren heen aan deze projecten hadden toegevoegd. Ze zochten naar momenten waarop een ontwikkelaar moest stoppen om een specifieke onderhoudskwestie te verhelpen die gerelateerd was aan de verbinding tussen de twee talen. Om de enorme hoeveelheid gegevens te verwerken, gebruikten ze een geavanceerde kunstmatige intelligentie-tool om de wijzigingen in de code en de aantekeningen die ontwikkelaars erover schreven te lezen. De AI fungeerde als een zeer bekwame assistent die door de wijzigingen scande om de specifieke problemen te identificeren die een ontwikkelaar probeerde op te lossen, zoals het verhelpen van een geheugenlek, het beveiligen van een gegevensoverdracht, of het herorganiseren van de manier waarop twee onderdelen van het systeem met elkaar communiceren. De onderzoekers controleerden vervolgens handmatig een steekproef van deze bevindingen om te controleren of de AI correct was, waarmee ze bevestigden dat de methode betrouwbaar was.
De studie bracht een duidelijk beeld aan het licht van waar ontwikkelaars daadwerkelijk mee worstelen. Ze identificeerden elf verschillende families van problemen die steeds weer opduiken. De meest voorkomende problemen hadden betrekking op het veilig houden van de grens tussen de twee talen en het waarborgen dat middelen, zoals geheugen of bestandshandelingen, na gebruik correct worden opgeruimd. Deze twee categorieën alleen al waren verantwoordelijk voor bijna zestig procent van al het onderhoudswerk dat de onderzoekers vonden. Dit suggereert dat het meest urgente dagelijkse werk voor deze ontwikkelaars simpelweg het in stand houden van de verbinding tussen de talen is, zodat deze niet breekt of lekt. Echter, toen de onderzoekers deze real-world problemen vergeleken met de bestaande lijsten van bekende "code smells", ontdekten ze een aanzienlijke kloof. De huidige catalogi, die grotendeels door experts zijn gemaakt op basis van theoretische ontwerpprincipes, dekten slechts ongeveer zesendertig procent van de werkelijke problemen die ontwikkelaars oplosten. Met andere woorden, de bestaande lijsten misten de meerderheid van het werk dat ontwikkelaars verrichtten om hun software gezond te houden.
De onderzoekers realiseerden zich dat de ontbrekende problemen geen willekeurige fouten waren, maar terugkerende patronen die hun eigen naam verdienden. Ze ontdekten dat ontwikkelaars vaak gecoördineerde wijzigingen moesten aanbrengen in zowel de Java-code als de C-code telkens wanneer één enkel detail veranderde, een situatie die updates traag en foutgevoelig maakte. Ze zagen ook gevallen waarin de software interne details over de taalgrens heen blootstelde, wat de beveiliging en organisatie van het systeem verzwakte. Tot slot merkten ze op dat verantwoordelijkheden vaak in de verkeerde taal werden geplaatst, waardoor één kant van het systeem de andere kant constant moest vragen om zijn werk te doen, wat onnodige complexiteit creëerde. Op basis van deze herhaalde observaties stelde het team drie nieuwe definities voor code smells voor die specifiek deze cross-language kwesties adresseren. Ze noemden ze Cross-Language Shotgun Surgery, wat de noodzaak beschrijft om veel bestanden tegelijk te wijzigen; Cross-Language Abstraction Leakage, waarbij verborgen details per ongeluk worden blootgesteld; en Wrong Responsibility Allocation, waarbij taken aan de verkeerde taallaag worden toegewezen.
Dit werk verschuift de focus van wat experts denken dat een probleem zou moeten zijn naar wat ontwikkelaars daadwerkelijk oplossen. Door te luisteren naar de geschiedenis van de software zelf, lieten de onderzoekers zien dat het huidige begrip van multi-language designfouten incompleet is. De bestaande lijsten zijn goed in het vangen van eenvoudige, lokale fouten, maar ze missen de diepere architecturale uitdagingen die ontstaan wanneer twee verschillende werelden van code proberen samen te werken. De nieuwe definities bieden een vocabulaire voor deze verborgen strijdpunten, en bieden een manier voor ontwikkelaars om deze specifieke soorten puinhopen te herkennen en op te lossen voordat ze onbeheersbaar worden. De studie concludeert dat om de softwarekwaliteit echt te begrijpen, we niet alleen naar de statische code moeten kijken, maar naar de lange, rommelige geschiedenis van hoe die code in leven wordt gehouden en evolueert.
Verdrinkt u in papers in uw vakgebied?
Ontvang dagelijkse digests van de nieuwste papers die bij uw onderzoekswoorden passen — met technische samenvattingen, in uw taal.