Integrating Structural and Semantic Analysis for Code Smell Refactoring Prediction

Il software non è mai veramente finito. Come una città che cresce organicamente nel corso di decenni, un programma per computer accumula strati di aggiunte, patch e correzioni rapide. Con il tempo, questa crescita organica può portare a debolezze strutturali, proprio come un edificio in cui un corridoio è stato allargato senza rinforzare le pareti. Nel mondo dell'ingegneria del software, queste falle localizzate sono note come "code smells" (odori del codice). Non sono errori che causano il crash di un programma, ma piuttosto segni di una cattiva progettazione che rendono il codice difficile da comprendere, modificare o mantenere. Quando gli sviluppatori individuano questi "odori", spesso effettuano il "refactoring", un processo attento di riorganizzazione del codice per migliorarne la struttura senza cambiare ciò che il software effettivamente fa. La sfida è che gli sviluppatori non sempre correggono ogni odore che trovano, e prevedere quali verranno corretti è difficile perché la decisione dipende spesso dall'intento umano e dal contesto, non solo dal codice stesso.

Un team di ricercatori dell'Università di Milano-Bicocca ha deciso di vedere se le macchine potessero imparare a prevedere queste decisioni umane. Volevano sapere se un computer potesse guardare un pezzo di codice, identificare un difetto e indovinare con precisione se uno sviluppatore lo avrebbe eventualmente pulito. Per farlo, hanno costruito un sistema che combina due modi diversi di osservare il codice. Il primo modo è tradizionale: contare proprietà come la lunghezza di un metodo o quanti variabili utilizza. Il secondo modo è più moderno e complesso: trasformare il codice in una mappa della sua logica e del suo comportamento, per poi tradurre questa mappa in una rappresentazione matematica che un computer possa analizzare alla ricerca di schemi nascosti. Alimentando queste informazioni combinate in modelli di apprendimento automatico, i ricercatori hanno testato se i computer potessero apprendere le regole sottili che guidano gli sviluppatori quando scelgono di effettuare il refactoring.

I ricercatori hanno raccolto dati da 79 progetti Java open-source, una collezione di software che era stata sviluppata e mantenuta da molte persone nel tempo. Hanno utilizzato strumenti automatizzati per scansionare la cronologia di questi progetti, identificando migliaia di istanze in cui erano presenti "code smells" e tracciando quali di essi fossero stati successivamente corretti attraverso specifiche azioni di refactoring, come rinominare una variabile, estrarre un metodo in un pezzo più piccolo o cambiare un parametro. Hanno poi creato un dataset ibrido per ogni pezzo di codice. Questo dataset includeva misurazioni standard, come il numero di righe in un metodo, insieme a due diversi tipi di "embedding". Un tipo di embedding mappava il flusso di controllo, mostrando l'ordine in cui vengono eseguite le istruzioni. L'altro tipo, più avanzato, mappava le relazioni semantiche più profonde, catturando come i dati si muovono attraverso il programma e come le diverse parti del codice dipendono l'una dall'altra, creando di fatto un ritratto ricco e multidimensionale del comportamento del codice.

I risultati hanno mostrato che i modelli di apprendimento automatico sono effettivamente capaci di prevedere il refactoring con un alto grado di affidabilità. Quando i modelli sono stati testati su dieci diversi tipi di operazioni di refactoring, hanno frequentemente raggiunto punteggi AUC ben superiori a 0,70 e, per alcuni compiti, hanno superato lo 0,80. Ciò suggerisce che esistono effettivamente schemi rilevabili nel codice che segnalano l'intento di uno sviluppatore di pulirlo. Tuttavia, lo studio ha rivelato una sfumatura cruciale: non tutti i "code smells" sono creati uguali. I modelli sono stati eccezionalmente bravi a prevedere cambiamenti strutturali, come l'aggiunta di un parametro a un metodo o il cambiamento del tipo di una variabile. Queste azioni sono spesso guidate da fattori chiari e misurabili, come la lunghezza di un'istruzione o la complessità di un calcolo. Al contrario, i modelli hanno faticato a prevedere cambiamenti più concettuali, come la rinomina di un metodo. La rinomina è spesso una decisione soggettiva basata su come uno sviluppatore concepisce lo scopo del codice, un fattore difficile da catturare solo con numeri o mappe strutturali.

Forse il risultato più significativo riguardava il tipo di rappresentazione dei dati utilizzato. I ricercatori inizialmente si aspettavano che l'aggiunta di mappe più complesse del flusso di esecuzione del codice avrebbe semplicemente migliorato le previsioni. Invece, hanno scoperto che un tipo specifico di mappa di flusso, che tracciava l'ordine delle istruzioni, introduceva rumore che confondeva i modelli. Quando questa mappa di flusso veniva combinata con le misurazioni tradizionali, spesso rendeva le previsioni peggiori, poiché il computer faticava a ignorare i dettagli irrilevanti. Tuttavia, quando i ricercatori sono passati alla rappresentazione più avanzata che combinava le dipendenze strutturali con il testo e la logica effettiva del codice, i risultati sono cambiati drasticamente. Questa rappresentazione più ricca forniva un segnale complementare che i modelli potevano utilizzare efficacemente. Infatti, per alcuni compiti, i modelli addestrati esclusivamente su questa rappresentazione avanzata hanno ottenuto prestazioni quasi pari a quelli addestrati sull'intero dataset, dimostrando che la profonda comprensione strutturale e semantica del codice è, di per sé, un potente predittore.

Lo studio ha anche evidenziato i limiti di ciò che può essere predetto dal solo codice. Mentre i modelli potevano prevedere con affidabilità correzioni tecniche guidate dalla complessità, non riuscivano facilmente a prevedere le decisioni umane dietro la rinomina o la riorganizzazione del codice per chiarezzza. Ciò suggerisce che, sebbene le macchine possano essere eccellenti nell'identificare quando un software è tecnicamente in attesa di manutenzione, la decisione finale di effettuare il refactoring dipende spesso dalla visione e dal contesto di uno sviluppatore che esistono al di fuori del codice stesso. La ricerca conclude che il futuro della manutenzione del software automatizzata non risiede nel sostituire il giudizio umano, ma nell'utilizzare questi strumenti predittivi per evidenziare i debiti strutturali più urgenti, permettendo agli sviluppatori di concentrare il loro tempo limitato sui cambiamenti che contano di più. Comprendendo quali segnali sono forti e quali sono rumore, possiamo costruire strumenti migliori per aiutare a mantenere la nostra infrastruttura digitale sana e sostenibile.