Migliorare il rilevamento del debito tecnico con BERT

Nello sviluppo software, "Debito tecnico" si riferisce ai compromessi che i programmatori fanno quando scelgono una soluzione rapida invece di una più completa. Questo di solito succede per velocizzare la consegna di funzionalità o versioni del software. Il termine "Debito Tecnico Auto-Riconosciuto" (SATD) descrive il debito tecnico che i programmatori riconoscono nei loro commenti nel codice. Riconoscere e affrontare il SATD è importante perché può aumentare significativamente i costi di manutenzione dei progetti software nel tempo. Gli studi suggeriscono che il debito tecnico può rappresentare dal 20% al 40% del valore di un progetto software prima dell'ammortamento. Quindi, rilevare tempestivamente il SATD consente agli ingegneri del software e ai decisori di gestirlo in modo efficace.

#Sfida nel Rilevare il SATD

Rilevare il SATD nei commenti del codice sorgente è complicato a causa dello sbilanciamento tra commenti SATD e commenti non SATD. Ad esempio, in alcuni dataset, i commenti SATD rappresentano solo l'1,27% del totale dei commenti. Questa piccola rappresentazione rende difficile classificare i commenti in modo accurato. In molti casi, un dataset potrebbe avere solo pochi commenti SATD disponibili per i test, rendendo difficile valutare i metodi di rilevazione.

Ricerche passate hanno mostrato che alcune frasi possono segnalare commenti SATD, come "todo" o "hack." Tuttavia, i metodi esistenti spesso non tengono conto di quanto possa essere difficile classificare questi commenti, specialmente quando i dataset hanno caratteristiche diverse.

Inoltre, molti studi non utilizzano metodi affidabili come la validazione incrociata K-fold stratificata per valutare i loro risultati. Questo può portare a benchmark poco chiari quando si confronta la performance di classificazione tra metodi diversi.

#Nuovo Approccio alla Rilevazione del SATD

Per migliorare la rilevazione del SATD, abbiamo adottato un modello più recente chiamato BERT, progettato per elaborare il linguaggio. Il nostro studio ha coinvolto due approcci principali: uno in cui abbiamo addestrato il modello BERT usando commenti provenienti da vari progetti software (cross-project), e un altro in cui l'abbiamo addestrato usando commenti di un singolo progetto (intra-project).

Ci siamo proposti di applicare diverse tecniche per migliorare l'Elaborazione dei dati. Per lo scenario cross-project, abbiamo addestrato il modello su commenti provenienti da 19 repository e lo abbiamo testato sul rimanente. Per lo scenario intra-project, abbiamo addestrato il modello sul 90% dei commenti di un progetto e usato il restante 10% per valutare le sue performance.

#Tecniche di Elaborazione dei Dati

Prima di inserire i dati nel modello BERT, abbiamo preparato i commenti per assicurarci che il modello potesse capirli meglio. Abbiamo usato un tokenizer che gestisse il testo in modo appropriato, tenendo conto del mix di linguaggio colloquiale ed elementi simili al codice nei commenti. Ad esempio, abbiamo formattato i commenti per adattarci alle migliori pratiche di Java per la denominazione delle variabili.

Abbiamo anche ampliato il vocabolario del tokenizer BERT. Questo ha comportato l'identificazione di parole nel nostro dataset che non erano già riconosciute dal tokenizer e la loro aggiunta. Ci siamo proposti di sviluppare un tokenizer universale che potesse gestire sia il linguaggio naturale che gli elementi di codifica in modo efficace.

#Addestramento e Aumento dei Dati

Durante il nostro studio, abbiamo incluso diverse strategie per affrontare il problema dell'impatto dei dati relativi ai commenti SATD e non SATD. Una di queste strategie ha coinvolto l'uso del "Forced Minority Re-sampling." Questo significava che durante l'addestramento, ci assicuriamo che i commenti SATD fossero inclusi nei lotti più spesso, specialmente quando i commenti non SATD dominavano i lotti.

Oltre al re-sampling, abbiamo anche esplorato l'aumento dei dati duplicando i commenti SATD rimuovendo le parole chiave che segnalavano il debito tecnico. Ad esempio, un commento che originariamente diceva "// FIXME: Questo dovrebbe probabilmente..." potrebbe essere riformulato in "Questo dovrebbe probabilmente..." per creare una nuova voce mantenendo il significato.

#Risultati dal Modello BERT

Nelle nostre valutazioni cross-project, il modello BERT ha mostrato risultati impressionanti migliorando le performance rispetto ai metodi esistenti in quasi tutti i casi utilizzando i dataset forniti. Tuttavia, nelle valutazioni intra-project, i risultati erano meno favorevoli. Le performance non hanno raggiunto quelle di altri approcci in media. Le nostre scoperte supportano l'idea che avere più dati porta a risultati migliori quando si addestrano modelli come BERT.

I risultati suggeriscono che, mentre il modello potrebbe identificare bene i commenti SATD quando addestrato su dataset completi, ha avuto difficoltà con dataset più piccoli tratti da progetti singoli. I risultati hanno anche dimostrato che le tecniche esistenti hanno ancora performato meglio in scenari con dati limitati.

#Direzioni Future per la Ricerca sul SATD

Andando avanti, la classificazione dei commenti SATD beneficerebbe molto di metodi più raffinati che distinguano tra commenti più facili e più difficili. Identificando quali commenti sono più facili da classificare e quali sono più impegnativi, possiamo sviluppare modelli migliori che tengano conto di queste informazioni.

Inoltre, vediamo la necessità di tecniche di aumento dei dati migliori per sfruttare al massimo modelli NLP come BERT quando i dataset sono scarsi. Questo potrebbe comportare l'esplorazione di nuovi modi per sostituire parole con sinonimi o generare ulteriori esempi di addestramento basati sui commenti che già abbiamo.

#Conclusione

In sintesi, la nostra esplorazione nella rilevazione dei commenti SATD usando il modello BERT mostra che, sebbene possano avvenire miglioramenti significativi con abbastanza dati, rimangono sfide in situazioni con dati limitati. Lo studio sottolinea l'importanza di utilizzare tecniche di elaborazione dei dati appropriate e di cercare continuamente modi migliori per aumentare i dataset per ottenere risultati più affidabili. Man mano che perfezioniamo la nostra comprensione e i metodi in questo campo, apriamo la strada a una gestione più efficace del debito tecnico nei progetti software, portando infine a una migliore qualità del software e costi di manutenzione inferiori.