🤖 AI

Automated Classification of Source Code Changes Based on Metrics Clustering in the Software Development Process

Questo articolo presenta un metodo automatizzato per classificare le modifiche al codice sorgente mediante clustering dei relativi metrici, utilizzando l'algoritmo k-means con similarità coseno su undici indicatori per ridurre i tempi di revisione, come dimostrato dalla validazione su cinque sistemi software.

Autori originali: Evgenii Kniazev

Pubblicato 2026-02-17

📖 4 min di lettura☕ Lettura da pausa caffè

CC BY 4.0

Autori originali: Evgenii Kniazev

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

🛠️ Il Problema: Troppa "Rumore" nella Cucina del Software

Immagina di essere il capo cuoco di un ristorante molto famoso (il software). Ogni giorno, i tuoi cuochi modificano le ricette: aggiungono un nuovo ingrediente, cambiano il modo di tagliare le verdure, o correggono un errore di un'etichetta.

Ogni volta che una ricetta cambia, il capo cuoco deve controllarla per assicurarsi che sia tutto a posto. Ma se il ristorante è enorme e ci sono migliaia di piccole modifiche ogni giorno, il capo cuoco impazzirebbe. Non ha tempo di leggere ogni singola nota a margine.

Quale modifica è un nuovo piatto delizioso?
Quale è solo una correzione di un errore?
Quale è un riordino della dispensa (refactoring)?

Se il capo cuoco controlla tutto a mano, il ristorante si ferma. Se non controlla nulla, si rischiano piatti rovinati.

💡 La Soluzione: Il "Filtro Intelligente"

Il dottor Evgenii Knyazev ha inventato un filtro intelligente (un algoritmo) che aiuta il capo cuoco a organizzare queste modifiche senza doverle leggere tutte una per una.

Ecco come funziona, passo dopo passo, con delle metafore:

1. Misurare le Modifiche (I "Fatti" della ricetta)

Invece di leggere il testo della ricetta, il sistema guarda i numeri. Per ogni modifica, calcola delle "misure":

Quante righe di testo sono state aggiunte?
Quante sono state cancellate?
La ricetta è diventata più complessa o più semplice?
Quanti nuovi ingredienti (classi o interfacce) sono stati introdotti?

È come se il sistema pesasse ogni ingrediente aggiunto o tolto, senza preoccuparsi del sapore, ma solo della quantità e del tipo.

2. Il Raggruppamento Magico (Il "Clustering")

Qui entra in gioco la vera magia. Il sistema prende tutte queste modifiche misurate e le butta in una stanza piena di cestini.
Usa un metodo chiamato k-means (immagina un gioco di "chi è più simile a chi").

Se una modifica ha aggiunto 10 righe di codice e cancellato 2, il sistema la mette nel cestino delle "piccole correzioni".
Se una modifica ha riscritto metà della ricetta e aggiunto 50 righe, la mette nel cestino delle "grandi novità".

Il sistema non sa ancora cosa sono queste modifiche (se sono bug o nuove funzioni), ma sa che si assomigliano molto tra loro. È come raggruppare le mele con le mele e le arance con le arance, basandosi solo sul peso e sul colore, senza sapere che sono frutta.

3. L'Esperto dà il Nome (La Mappatura)

Ora che le modifiche sono raggruppate in cestini, il sistema chiama il Capo Cuoco Esperto (l'umano).
Il sistema dice: "Guarda questo cestino. Contiene 50 modifiche che sembrano tutte piccole correzioni. Tu cosa dici? È un cestino di 'Bug Fix' o di 'Nuove Funzioni'?"

L'esperto guarda solo un piccolo campione di quel cestino (ad esempio, 3 o 4 modifiche) e dice: "Sì, questo è un cestino di correzioni di errori".
Da quel momento, il sistema sa che tutto ciò che finisce in quel cestino è una correzione di errori. Non deve più chiedere all'esperto per le altre 47 modifiche.

📊 I Risultati: Quanto è bravo?

Il dottor Knyazev ha testato questo metodo su software reali (come Subversion e NHibernate, che sono come i "motori" di molti siti web).
I risultati sono stati sorprendenti:

Il sistema ha classificato correttamente circa il 75% delle modifiche da solo.
Ha risparmiato agli esperti umani un tempo enorme: invece di dover controllare 2.000 modifiche, ne hanno dovute controllare solo 73 per insegnare al sistema come raggrupparle.

È come se un assistente robotico avesse ordinato 2.000 libri in 10 scaffali diversi, e tu avessi dovuto solo dire: "Sì, quello scaffale è per la storia, quello per la scienza". Da quel momento, il robot ha sistemato tutto il resto da solo.

🚀 Perché è importante?

Prima di questo metodo, gli sviluppatori dovevano leggere ogni singola modifica per capire cosa stava succedendo nel software. Era lento, costoso e noioso.
Ora, con questo metodo:

Risparmio di tempo: Gli esperti si concentrano solo sui casi difficili o sui gruppi da etichettare.
Qualità: Si trovano errori prima che il software venga rilasciato.
Flessibilità: Se domani il capo cuoco vuole cambiare le regole (ad esempio, vuole separare le "correzioni di grammatica" dalle "correzioni di ingredienti"), basta dire al sistema di fare nuovi gruppi. Non serve riscrivere tutto il programma.

In Sintesi

Questo lavoro è come aver dato a un team di sviluppatori un assistente intelligente che non legge le storie, ma guarda i numeri per capire se una modifica è una "piccola ritoccatura", una "grande novità" o una "pulizia". L'umano fa solo il supervisore, mentre il robot fa il lavoro pesante di ordinamento.

Titolo: Classificazione Automatizzata delle Modifiche al Codice Sorgente Basata sul Clustering di Metriche

Autore: Evgenii G. Knyazev (Università ITMO, San Pietroburgo)
Origine: Traduzione dell'abstract della tesi di dottorato (2009), pubblicata su arXiv nel 2026.

1. Il Problema

Nello sviluppo software moderno, le organizzazioni gestiscono volumi enormi di codice sorgente, rendendo la comprensione, l'analisi e il controllo qualità estremamente complessi. La revisione del codice (code review) è fondamentale per rilevare difetti (errori algoritmici, violazioni dello stile, codice inutilizzato) in fase precoce. Tuttavia, il processo di revisione manuale è estremamente dispendioso in termini di tempo.

Sebbene i sistemi di controllo versione (VCS) forniscano la cronologia delle modifiche, il numero elevato di cambiamenti rende impossibile una revisione completa. È necessario selezionare quali modifiche esaminare, ma la classificazione manuale delle modifiche (es. nuova funzionalità, refactoring, correzione di bug, formattazione) richiede l'intervento di esperti qualificati e consuma risorse significative. Le soluzioni esistenti basate su parole chiave, alberi sintattici o data mining presentano limiti come la rigidità, la dipendenza dal linguaggio di programmazione o la necessità di set di addestramento complessi.

2. Metodologia Proposta

L'autore propone un metodo ibrido per la classificazione automatizzata delle modifiche al codice, basato su due fasi principali: clustering automatico e mappatura esperta.

Fase 1: Calcolo delle Metriche di Modifica

Per ogni modifica al codice ( $\delta$ ), viene calcolato un vettore di metriche ( $\mu$ ). Il documento utilizza 11 metriche specifiche che coprono:

Linee di codice (LOC): Aggiunte, eliminate e modificate.
Complessità Ciclomatica (CC): Per il codice aggiunto, eliminato e modificato.
Struttura: Numero di file modificati, interfacce aggiunte/eliminate, classi e strutture aggiunte/eliminate.
Le modifiche sono rappresentate come script di modifica (inserimenti, cancellazioni, sostituzioni) derivati dagli script di edit.

Fase 2: Clustering dei Vettori

I vettori di metriche vengono raggruppati utilizzando l'algoritmo k-means.

Misura di similarità: Viene utilizzata la somiglianza del coseno ( $\cos(\theta)$ ) invece della distanza euclidea. Questo è cruciale perché la similarità del coseno ignora la scala (lunghezza del vettore) e si concentra sulla direzione, permettendo di distinguere le classi di modifiche indipendentemente dalla dimensione della modifica (es. una piccola correzione di bug e una grande nuova funzionalità possono essere simili nella "direzione" delle metriche).
Ottimizzazione: Il numero di cluster ( $k$ ) viene inizialmente impostato uguale al numero di classi esperte, ma può essere incrementato se la qualità del clustering (misurata da una funzione di densità $I$ ) non è sufficiente.

Fase 3: Mappatura Esperta e Classificazione

Un esperto analizza un campione di modifiche all'interno di ogni cluster (scelto in base alla vicinanza al centroide).
Sulla base della predominanza di una certa classe nel campione, l'intero cluster viene mappato a una classe predefinita (es. "Bug Fix", "Refactoring").
Una volta stabilita la mappatura, tutte le modifiche nel cluster vengono classificate automaticamente.

3. Contributi Chiave

Automazione Parziale: Dimostrazione che è possibile automatizzare la distribuzione delle modifiche in gruppi omogenei, riducendo drasticamente il carico di lavoro manuale.
Scelta dell'Algoritmo: Giustificazione teorica ed empirica dell'uso di k-means con similarità del coseno per le metriche di modifica, superando i limiti delle metriche basate sulla scala assoluta.
Metodo Ibrido: Un approccio che combina l'efficienza computazionale del clustering non supervisionato con la precisione semantica della validazione esperta, evitando la necessità di grandi set di dati etichettati per l'addestramento (come richiesto dal data mining supervisionato).
Implementazione Software: Sviluppo di un tool che integra il calcolo delle metriche, l'analisi degli script di modifica (basato su Subversion) e il clustering (basato su CLUTO).

4. Risultati Sperimentali

Il metodo è stato validato su cinque sistemi software, inclusi due progetti open-source (Subversion e NHibernate) e sistemi industriali sviluppati da Transas Technologies.

Caso Studio NHibernate:
- Dati: 2.069 modifiche totali.
- Processo: Le modifiche sono state raggruppate in 12 cluster. Solo 73 modifiche sono state classificate manualmente dall'esperto per mappare i cluster alle classi (invece di revisionare tutte le 2.069).
- Qualità della Classificazione:
  - Purezza ( $P_C$ ): $0.75 \pm 0.05$ (circa il 75% delle modifiche è stato classificato correttamente).
  - Entropia ( $E_C$ ): $0.37 \pm 0.06$ (bassa incertezza nella distribuzione).
- Significatività: I risultati sono stati validati con un livello di significatività di 0.05 utilizzando il metodo di bootstrap resampling.
Limiti: La qualità diminuisce quando le modifiche combinano modifiche eterogenee (es. refactoring e correzione di bug nella stessa commit), rendendo difficile la separazione dei cluster.

5. Significatività e Impatto

Riduzione dei Tempi: Il metodo permette di ridurre drasticamente il tempo dedicato alla revisione del codice, poiché gli esperti devono solo validare la mappatura dei cluster e non ogni singola modifica.
Controllo del Processo: Facilita il monitoraggio della qualità dello sviluppo (es. assicurando che in fase di stabilizzazione vengano apportate solo correzioni di bug).
Applicabilità Industriale: Il metodo è già stato implementato e utilizzato con successo in progetti reali (sistemi di monitoraggio navale, simulatori di formazione) e in progetti open-source.
Flessibilità: A differenza di approcci basati su regole fisse, questo metodo può essere riconfigurato per diverse tassonomie di classi di modifiche semplicemente cambiando la mappatura esperta dei cluster.

In conclusione, la tesi dimostra che il clustering di metriche di modifica è una soluzione praticabile ed efficace per l'automazione parziale della classificazione del codice, offrendo un compromesso ottimale tra automazione e accuratezza semantica.