CLEM: A Behavior-Centric Software Quality Measurement Framework for Structural Change Monitoring

Immagina di guardare una città che cresce. Potresti contare quanti mattoni vengono posati ogni giorno, oppure potresti controllare se il consiglio comunale ha seguito le regole. Ma c'è un terzo modo, più interessante, per osservare una città: guardare come gli edifici cambiano. Le persone abbattono vecchie pareti per aggiungere una nuova stanza? Costruiscono un'ala nuova che si attacca al lato senza toccare la casa principale? Cambiano semplicemente un interruttore per modificare l'illuminazione? O si limitano a riorganizzare i mobili? Nel mondo del software, questa è esattamente la domanda che i ricercatori si pongono. Il software non è solo codice; è un sistema vivente che deve cambiare costantemente per rimanere utile. Se un sistema cambia solo abbattendo le proprie pareti, alla fine diventa un ammasso instabile e pericoloso. Ma se cambia aggiungendo nuove ali o azionando interruttori, rimane forte e flessibile. Questo è il cuore della "qualità del software": non solo se il codice funziona oggi, ma se può continuare a crescere senza crollare domani.

Questo articolo presenta un nuovo strumento chiamato CLEM (Change Localization and Externalization Measurement) per rispondere a questa domanda. Invece di limitarsi a contare quanto codice è stato cambiato, CLEM agisce come un detective che osserva come gli sviluppatori riparano o aggiornano un sistema. Classifica ogni modifica in quattro "personaggi":

1. Modifica (M): L'approccio "Abbatti la parete". Cambiare direttamente il codice centrale. È veloce ma rischioso, come scavare un buco in una parete per aggiungere una porta.
2. Estensione (E): L'approccio "Add-on". Costruire nuove funzionalità che si collegano al sistema senza toccare il nucleo, come aggiungere una nuova stanza a una casa.
3. Low-code (L): L'approccio "Diagramma di flusso". Usare strumenti visivi o regole per cambiare il comportamento, come un manager aziendale che riorganizza un flusso di lavoro senza scrivere codice.
4. Configurazione (C): L'approccio "Interruttore". Cambiare solo impostazioni o parametri, come girare una manopola per regolare il volume.

I ricercatori hanno testato questa idea su tre diversi progetti software: due pubblici provenienti da un grande ecosistema tecnologico e un'app privata per l'assistenza sanitaria. Hanno scoperto che CLEM può distinguere chiaramente tra un sistema "sano" (che usa principalmente add-on e interruttori) e uno "malato" (che scava costantemente nel proprio nucleo). Tuttavia, hanno anche scoperto qualcosa di sorprendente: sapere come un sistema cambia non predice automaticamente se avrà più bug il mese prossimo. È un ottimo strumento per comprendere la struttura di un sistema, ma non è una palla di cristallo per prevedere errori futuri.

Il nuovo taccuino del detective: Come funziona CLEM

Pensa allo sviluppo del software come a una cucina frenetica. Per anni, gli chef (sviluppatori) sono stati misurati in base a quanti piatti cucinano (volume di attività) o quanto è pulita la cucina alla fine della serata (controlli statici del codice). Ma cosa succederebbe se la cucina stesse cadendo a pezzi perché ogni volta che serve una nuova spezia, devono abbattere una parete per raggiungere la dispensa? Questo è il problema che CLEM risolve. Non si limita a contare i piatti; osserva il metodo che gli chef usano per procurarsi gli ingredienti.

L'articolo propone che ogni volta che un sistema software viene aggiornato, la modifica avviene in uno di quattro modi, e la combinazione di questi modi dice tutto sulla salute del sistema.

• La Modifica (M) è il metodo "Brute Force". È come uno chef che prende un maglio per rompere una parete perché ha bisogno di un nuovo scaffale. Fa il lavoro velocemente, ma se lo fai troppo spesso, l'intero edificio diventa instabile.
• L'Estensione (E) è il metodo "Modulare". È come costruire un carrello nuovo e staccabile che rotola nella cucina. Lo chef non tocca le pareti; aggiunge solo un nuovo strumento. Questo è più sicuro e mantiene intatta la struttura centrale.
• Il Low-code (L) è il metodo "Progetto". Immagina un manager che disegna un nuovo flusso su una lavagna che dice ai robot cosa fare, senza che i robot debbano essere riprogrammati. È un modo di cambiare le cose a un livello superiore.
• La Configurazione (C) è il metodo "Manopola". Si tratta solo di girare una manopola per rendere il forno più caldo o le luci più luminose. Non serve alcuna costruzione.

Gli autori sostengono che un sistema software sano e duraturo dovrebbe fare maggiore affidamento su Estensione, Low-code e Configurazione, e meno sulla Modifica. Se un sistema sta costantemente "Modificando" il proprio nucleo, sta probabilmente accumulando "debito tecnico" — un modo elegante per dire che sta prendendo in prestito stabilità dal futuro e dovrà restituirla con gli interessi in seguito.

L'esperimento: Osservare tre cucine

Per vedere se questa idea funziona, i ricercatori hanno fatto una visita sul campo in tre diverse "cucine" (repository software). Non si sono limitati a guardare i piatti finali; hanno osservato le mani degli chef per mesi.

1. La cucina "Fit" (fit-framework): Questo era un progetto pubblico progettato come un sistema di plugin. Si aspettavano che fosse pieno di "Estensioni" (E).
2. La cucina "App" (app-platform): Questo era un altro progetto pubblico, ma costruito per il design visivo low-code. Si aspettavano che fosse pieno di "Low-code" (L) e "Configurazione" (C).
3. La cucina "Antisuger": Questa era un'app privata per la gestione dello zucchero nel sangue. È stata costruita da un team diverso con strumenti diversi. Si aspettavano che fosse in una fase iniziale e caotica, probabilmente piena di "Modifiche" (M).

I ricercatori hanno analizzato 607 aggiornamenti specifici (commit) attraverso questi progetti. Hanno utilizzato un insieme di regole trasparenti per esaminare i file che venivano modificati. Se un file si trovava in una cartella "plugin", lo contavano come Estensione. Se era un file di "flusso", lo contavano come Low-code. Se era un file di codice centrale, era una Modifica.

Cosa hanno scoperto: I sistemi erano diversi

I risultati confermarono esattamente ciò che la teoria della "cucina sana" prevedeva.

• L'App-platform era effettivamente molto "esteriorizzata". Circa il 69,5% dei suoi cambiamenti erano Estensioni, con pochissime modifiche dirette al nucleo. Il suo punteggio "CLEM-ES" (una misura di quanto il cambiamento sia stato spostato lontano dal nucleo) era un forte +0,685.
• Il Fit-framework era un mix. Aveva molte Estensioni (33,4%), ma anche una parte significativa di Modifiche (29,1%). Il suo punteggio era +0,418, mostrando che era più sano di un semplice caos, ma non così "esteriorizzato" come l'App platform.
• L'app sanitaria Antisuger era l'opposto. Era quasi interamente dominata dalle "Modifiche", con l'83,0% dei suoi cambiamenti che consistevano in edizioni dirette del nucleo. Il suo punteggio era -0,659, indicando che era ancora in una fase fragile di "abbattere le pareti".

Ciò ha dimostato che CLEM può individuare con successo la differenza tra un sistema che cresce aggiungendo ali e uno che cresce abbattendo pareti. I ricercatori hanno persino verificato se le loro regole fossero eque, facendo esaminare a due esseri umani 160 aggiornamenti casuali. Concordarono il 100% delle volte sulla categoria principale, il che suggerisce che le regole siano solide e riproducibili.

Il colpo di scena: La struttura non predice i bug (ancora)

Ecco la parte in cui l'articolo è molto cauto. Potresti pensare: "Se un sistema sta abbattendo le proprie pareti (alta Modifica), dovrebbe rompersi più spesso, giusto?". I ricercatori hanno testato questo aspetto. Hanno cercato di capire se i punteggi CLEM potessero predire se il mese successivo sarebbe stato pieno di "correzioni di bug".

La risposta? Nessun legame chiaro.
Nei loro dati, il punteggio di "Modifica" non ha predetto in modo affidabile se il mese successivo sarebbe stato pieno di correzioni di bug. Il punteggio "CLEM-ES" (quanto erano esteriorizzati i cambiamenti) aveva quasi zero correlazione con i futuri bug in questo campione specifico.

Questa è una scoperta cruciale. Gli autori affermano esplicitamente che CLEM non è una palla di cristallo magica per predire i difetti. Non sostituisce i vecchi modi di contare i bug o il turnover del codice. Al contrario, offre un tipo diverso di intuizione. Ti dice qualcosa sulla postura strutturale del sistema. Un sistema con un alto punteggio di Modifica potrebbe non avere più bug oggi, ma sta costruendo una struttura che è più difficile da mantenere e più incline a diventare fragile nel tempo. È come un edificio che è strutturalmente instabile; potrebbe non crollare oggi, ma il progetto è sbagliato.

Perché questo è importante

L'articolo conclude che CLEM è una nuova lente potente per i manager del software. Sposta la conversazione da "Quanto codice abbiamo scritto?" a "Come stiamo cambiando il nostro sistema?".

• Se vedi un team che fa costantemente Modifiche, è un segnale per fermarsi e chiedere: "Perché stiamo abbattendo le nostre stesse pareti? Possiamo costruire un plugin invece?".
• Se vedi un team che fa principalmente Estensioni e Configurazioni, suggerisce che il sistema sta maturando e diventando più stabile.

Gli autori sono onesti riguardo ai limiti del loro lavoro. Ammettono che il loro campione era piccolo (solo pochi mesi di dati da tre progetti) e che la parte di "predizione dei bug" non ha funzionato come sperato. Suggeriscono che CLEM sia meglio usato come uno strumento complementare — un modo per tenere d'occhio la salute strutturale di un sistema insieme alle metriche tradizionali. Non è un verdetto finale sulla qualità, ma un modo molto chiaro e verificabile per vedere se un sistema software sta imparando a crescere o se è bloccato nell'abitudine di distruggere la propria fondazione.

In breve, CLEM ci fornisce un vocabolario per parlare della forma del cambiamento. Ci aiuta a vedere se il nostro software sta costruendo un grattacielo o se sta solo impilando mattoni su una pila traballante, e questa distinzione potrebbe essere la cosa più importante che possiamo misurare per la sopravvivenza a lungo termine di qualsiasi sistema digitale.