Il ruolo della qualità del codice: parametri critici e il loro impatto

La qualità del codice è misurabile. Questa affermazione sembra ovvia finché non si cerca di rispondere alla domanda che un CTO si pone prima di acquistare un prodotto software, o un responsabile tecnico prima di impegnarsi in un programma di refactoring: come si fa a sapere se il codice è di buona qualità? "Funziona" non è una risposta. "Il team l'ha revisionato" non è una risposta. La risposta richiede misurazioni oggettive applicate in modo coerente: complessità ciclomica per funzione, indice di manutenibilità per modulo, densità di difetti per mille righe, copertura dei test per componente, numero di modifiche al codice per file per sprint. Ognuno di questi è un numero. I numeri possono essere analizzati, confrontati con parametri di riferimento e utilizzati per agire.

La difficoltà sta nel fatto che le metriche di qualità del codice non sono intercambiabili e non hanno un'interpretazione universale. Un indice di manutenibilità elevato in un programma COBOL ha un significato diverso rispetto allo stesso punteggio in uno script Python. Una complessità ciclomica di 15 è accettabile in una macchina a stati ben testata e rappresenta un grave problema in una funzione di validazione. Una densità di difetti di 2 bug per KLOC è eccellente nella programmazione di sistemi e allarmante in un'applicazione embedded critica per la sicurezza. Per rendere utili le metriche è necessario comprendere cosa misura ciascuna di esse, cosa ne influenza il valore e quali soglie sono appropriate al contesto. Il resto di questo articolo fornisce proprio questo.

Che cos'è la qualità del codice?

La qualità del codice è il grado in cui il codice sorgente soddisfa una serie di proprietà misurabili che lo rendono corretto, manutenibile, leggibile, efficiente, sicuro e testabile. Nessuna singola proprietà definisce la qualità in isolamento. Il codice che funziona correttamente ma è illeggibile si degrada in qualità a ogni modifica, perché gli sviluppatori che non lo comprendono non possono modificarlo in modo sicuro. Il codice leggibile ma non testato presenta difetti nascosti. Il codice testato ma strutturalmente complesso accumula più difetti man mano che cresce, perché la complessità moltiplica la probabilità che una data modifica causi un malfunzionamento imprevisto.

Una definizione formale dello standard ISO/IEC 25010 identifica otto caratteristiche di qualità del software: idoneità funzionale, efficienza prestazionale, compatibilità, usabilità, affidabilità, sicurezza, manutenibilità e portabilità. Nello specifico, per il codice sorgente, le caratteristiche che possono essere misurate direttamente dal codice stesso, anziché dal comportamento in fase di esecuzione, sono la manutenibilità, l'affidabilità (approssimata da metriche di difetti e complessità), la sicurezza (tramite analisi statica) e l'idoneità funzionale (tramite copertura dei test). Le altre caratteristiche richiedono l'esecuzione del codice per essere misurate. Le metriche di qualità del codice coprono quindi un sottoinsieme definito e importante della qualità del software, non la sua totalità.

Perché la qualità del codice è importante

I team tecnici sanno perché la qualità del codice è importante. Per gli stakeholder aziendali e per i team che devono giustificarne l'importanza internamente, il collegamento è in termini di costi e tempi. Studi condotti da McKinsey e dal Consortium for IT Software Quality (CISQ) dimostrano costantemente che gli sviluppatori dedicano tra il 30 e il 40% del loro tempo a risolvere problemi tecnici preesistenti, anziché sviluppare nuove funzionalità. La scarsa qualità del codice è il meccanismo attraverso il quale si accumula il debito tecnico: ogni difetto non individuato tempestivamente, ogni funzione più complessa del necessario, ogni blocco di logica duplicato che deve essere gestito separatamente, aumenta il costo della modifica successiva. Un'elevata qualità del codice riduce costantemente tale costo, con un effetto cumulativo per l'intero ciclo di vita del sistema.

Metriche di qualità del codice: riferimento completo

Le metriche riportate di seguito coprono tutte le principali categorie di misurazione della qualità del codice. Per ciascuna metrica, vengono illustrati la definizione, il metodo di misurazione, l'intervallo accettabile e l'interpretazione. Le soglie nella tabella sottostante riflettono i benchmark di settore ampiamente citati; i team che operano in ambienti critici per la sicurezza o regolamentati dovrebbero applicare soglie più rigorose.

Metriche di complessità

Complessità ciclomatica misura il numero di percorsi linearmente indipendenti attraverso una funzione o un metodo. È stata introdotta da Thomas McCabe nel 1976 e rimane la metrica di complessità più utilizzata. La formula conta i punti decisionali, if, else if, switch casi, condizioni di ciclo, catch blocchi, operatori condizionali e aggiunge 1. Una funzione senza ramificazioni ha una complessità ciclomica di 1.

Complessità ciclomatica	Interpretazione
1-5	Semplice, facile da testare
6-10	Moderato, gestibile
11-20	Complesso, i test diventano difficili
21-50	Rischio molto elevato, si consiglia di effettuare un refactoring.
50+	Impossibile da testare, quasi certamente contenente difetti

L'elevata complessità ciclomica è fortemente correlata alla densità dei difetti. Una ricerca pubblicata su IEEE Transactions on Software Engineering ha rilevato che le funzioni con complessità ciclomica superiore a 10 hanno tassi di difetti significativamente più elevati rispetto alle funzioni più semplici. Per analisi della complessità ciclomatica Nei codebase legacy, il problema è trovare funzioni che hanno accumulato logica decisionale nel corso di anni di manutenzione senza che nessuno abbia mai effettuato un refactoring della struttura complessiva.

Complessità NPath La complessità NPath conta il numero di percorsi di esecuzione unici attraverso una funzione, inclusi i percorsi creati da condizioni annidate e cicli. Mentre la complessità ciclomica conta i rami in modo lineare, la complessità NPath li moltiplica: una funzione con tre blocchi if-else sequenziali ha una complessità ciclomica di 4 ma una complessità NPath di 8, perché ogni condizione può essere vera o falsa indipendentemente. La complessità NPath cresce esponenzialmente con l'annidamento. Un valore superiore a 200 indica una funzione che richiederebbe più casi di test di quanti un team possa realisticamente scrivere.

Complessità cognitiva è stato introdotto da SonarSource e misura quanto è difficile comprendere il codice piuttosto che quanti percorsi contiene. Penalizza l'annidamento più pesantemente della ramificazione lineare: un if dentro a while dentro un altro if punteggi superiori a tre consecutivi if dichiarazioni con la stessa complessità ciclomica. La complessità cognitiva si allinea meglio con la difficoltà effettiva che gli sviluppatori riscontrano nella lettura del codice. Una complessità cognitiva superiore a 15 per metodo viene generalmente segnalata per una revisione; superiore a 25 indica una funzione che la maggior parte degli sviluppatori troverà effettivamente difficile da comprendere.

Metriche di Halstead Da quattro conteggi presenti nel codice sorgente si ricava una famiglia di misure: operatori distinti (n1), operandi distinti (n2), operatori totali (N1) e operandi totali (N2). Da questi, Halstead calcola:

• Volume (N × log2(n)): la dimensione dell'implementazione nel contenuto informativo
• Livello di difficoltà (n1/2 × N2/n2): una stima di quanto sia difficile scrivere o comprendere il codice
• Sforzo (Volume × Difficoltà): lo sforzo mentale totale stimato per implementare o comprendere il codice

Le metriche di Halstead sono particolarmente utili per confrontare funzioni di complessità ciclomica simile e determinare quale sia più difficile da comprendere. Una funzione con 10 ramificazioni su variabili chiaramente nominate ha una difficoltà di Halstead inferiore rispetto a una con 10 ramificazioni su indici calcolati e identificatori a singolo carattere.

Metriche di manutenibilità

Indice di manutenibilità È una metrica composita originariamente sviluppata da Paul Oman e Jack Hagemeister e successivamente adottata da Microsoft Visual Studio come misura standard di manutenibilità. Combina il volume di Halstead, la complessità ciclomica e il numero di righe di codice in un unico punteggio.

La formula di Visual Studio produce un punteggio da 0 a 100:

Indice di manutenibilità	Valutazione
20-100	Manutenibile (verde)
10-19	Problema di manutenzione di moderata entità (giallo)
0-9	Difficile da mantenere (rosso)

L'indice di manutenibilità è una statistica riassuntiva. È più utile per identificare valori anomali, file o moduli che ottengono un punteggio nella zona rossa, piuttosto che per un confronto dettagliato tra moduli nella zona verde. In Python, l' radon La libreria calcola direttamente l'indice di manutenibilità. In Visual Studio, appare nella finestra Metriche del codice. Per analisi statica del codice Nelle piattaforme, l'indice di manutenibilità è in genere uno degli output standard, insieme alla complessità ciclomica e al numero di righe di codice.

Righe di codice (LOC) e KLOC La dimensione del codice sorgente si misura in righe o migliaia di righe. Il numero di righe (LOC) da solo non dice nulla sulla qualità, ma fornisce denominatori essenziali per altre metriche: la densità dei difetti è il numero di bug per migliaia di righe, la densità dei commenti è il numero di commenti per riga, la densità dei test è il numero di asserzioni di test per riga. Il numero di righe (LOC) inoltre quantifica il costo della complessità: una funzione di 500 righe con una complessità ciclomica di 20 rappresenta un problema molto più grande di una funzione di 50 righe con lo stesso punteggio.

Codice Variazione Il tasso di modifica del codice nel tempo è misurato come numero di righe aggiunte, righe eliminate e righe modificate per file per unità di tempo. Un elevato tasso di modifica del codice indica instabilità: il codice che cambia frequentemente potrebbe essere la conseguenza di una progettazione errata fin dall'inizio, di requisiti instabili o di bug che richiedono continue patch. Una ricerca di Microsoft ha rilevato che i file che rientrano nel 10% con il più alto tasso di modifica del codice contenevano cinque volte più difetti rispetto ai file con un basso tasso di modifica. Monitorare il tasso di modifica del codice insieme al tasso di difetti permette di capire se le modifiche frequenti migliorano la qualità o generano nuovi problemi.

Metriche di copertura del codice

Copertura del test unitario È la percentuale di righe, rami o condizioni nel codice sorgente che vengono eseguite dai test unitari. La forma più significativa è la copertura dei rami: se ogni decisione nel codice può essere raggiunta da almeno un test sia nel caso di risultato vero che falso. La copertura delle righe è più facile da manipolare: un test che esegue ogni riga senza effettuare alcuna asserzione raggiunge il 100% di copertura delle righe e non rileva alcun errore.

Parametri di riferimento del settore per la copertura dei test unitari:

• Inferiore al 50%: inadeguato, la maggior parte dei difetti non verrà rilevata dai test
• 50-75%: moderato, percorsi principali coperti, casi limite probabilmente non rilevati
• 75-90%: ottimo per la maggior parte del codice applicativo
• Oltre il 90%: adatto per sistemi critici per la sicurezza o ad alta affidabilità

Copertura del codice nelle applicazioni critiche per la sicurezza segue standard più rigorosi. DO-178C per il software aeronautico e IEC 61508 per la sicurezza funzionale specificano requisiti di copertura (copertura MC/DC per i livelli di criticità più elevati) che vanno oltre quanto ottenibile con i test unitari standard. Il miglioramento della qualità del codice nelle applicazioni critiche per la sicurezza richiede strumenti di copertura che tengano traccia della copertura delle condizioni/decisioni e che possano produrre la documentazione formale richiesta dagli enti di certificazione.

Densità dei test La copertura completa la misurazione del numero di asserzioni di test rispetto alla dimensione del codice di produzione. Un'elevata copertura con una bassa densità di test può indicare test che eseguono codice senza verificarne significativamente il comportamento. Un'elevata densità di test con una bassa copertura indica test concentrati in una piccola porzione della codebase.

Metriche dei difetti

Densità di insetti (anche Densità di difetti) è il numero di difetti confermati per mille righe di codice (KLOC). È la misura quantitativa più diretta della correttezza del codice. I benchmark di settore di CISQ indicano che il software commerciale standard presenta in media circa 15-50 difetti per KLOC prima del test; dopo il test e il rilascio, il software commerciale di alta qualità in genere ha meno di 1 difetto per KLOC.

Risultati dell'analisi statica densità approssimativa dei difetti prima che i difetti vengano confermati tramite test o utilizzo in produzione. Strumenti come SonarQube, Checkmarx e SMART TS XL Analizza il codice sorgente alla ricerca di pattern associati a classi di difetti e vulnerabilità note, producendo un conteggio dei potenziali problemi categorizzati per gravità. Il rapporto tra i risultati critici e bloccanti e le righe di codice fornisce un segnale precoce della qualità del codice prima che questo raggiunga la fase di test.

Densità dell'odore del codice Il conteggio rileva la presenza di anti-pattern, codice duplicato, funzioni eccessivamente lunghe, accoppiamento eccessivo tra classi, feature envy e god object, per ogni KLOC. I code smell non causano guasti immediati, ma prevedono difetti futuri e costi di manutenzione. Una codebase con un'elevata densità di code smell è una codebase in cui il costo di ogni futura modifica è elevato, poiché ogni modifica deve gestire i problemi strutturali accumulati.

Metriche di leggibilità e stile

Commento Densità è il rapporto tra righe di commento e righe di codice. Gli intervalli ottimali variano a seconda del linguaggio e delle convenzioni del team, ma in genere sono compresi tra il 10 e il 30%. Al di sotto del 10% si può indicare un codice insufficientemente documentato; al di sopra del 50% si può indicare un codice così complesso da richiedere un'ampia spiegazione della logica non ovvia. La qualità dei commenti è più importante della quantità: un commento che ribadisce ciò che fa il codice (// increment i by 1) non aggiunge nulla, mentre un commento che spiega perché è stato scelto uno specifico algoritmo aggiunge un valore significativo.

Conformità alle convenzioni di denominazione Misura la percentuale di identificatori (variabili, funzioni, classi) che si conformano alle convenzioni di denominazione del progetto. Gli strumenti automatizzati possono imporre le convenzioni di denominazione come parte della configurazione del linting. Una denominazione coerente è uno dei miglioramenti più efficaci in termini di leggibilità, perché consente agli sviluppatori di prevedere lo scopo di un identificatore dal suo nome, riducendo il carico cognitivo derivante dalla lettura di codice sconosciuto.

Tasso di duplicazione del codice Questo indicatore misura la percentuale di codice duplicato in più posizioni. Una duplicazione superiore al 5% viene generalmente segnalata. Il codice duplicato moltiplica gli sforzi di manutenzione: un bug nella logica duplicata deve essere trovato e corretto in ogni copia, e le modifiche al comportamento devono essere applicate in modo coerente a tutte le copie. La duplicazione, inoltre, nasconde le dimensioni reali del codice: un sistema che sembra avere 100,000 righe potrebbe contenerne 40,000 di logica unica e 60,000 di copie.

Metriche relative al debito tecnico e di sicurezza

Rapporto debito tecnico SonarQube definisce il debito tecnico come il rapporto tra il costo stimato di bonifica e il costo stimato di sviluppo del codice sorgente. Un rapporto di debito tecnico inferiore al 5% è considerato indice di un codice sorgente pulito; un valore superiore al 20% indica un debito accumulato significativo che rallenterà notevolmente lo sviluppo futuro.

Densità dei punti critici di sicurezza Il sistema conta il numero di punti critici di sicurezza, ovvero modelli di codice che richiedono una revisione della sicurezza (non vulnerabilità confermate), per ogni KLOC (Kill Line of Code). Esempi includono query SQL non parametrizzate, utilizzo di funzioni crittografiche obsolete e gestione degli input non validata. Gli strumenti di analisi statica identificano questi modelli e li presentano come elementi che richiedono una revisione manuale della sicurezza.

Densità di vulnerabilità Questo indicatore conta le vulnerabilità di sicurezza confermate per KLOC, generalmente classificate in base alla gravità CVSS. È particolarmente utile nel contesto di audit di sicurezza post-rilascio o di pipeline di monitoraggio continuo della sicurezza.

Come misurare la qualità del codice: un approccio pratico

La misurazione della qualità del codice non è un'azione isolata, ma una pratica continua integrata nel flusso di lavoro di sviluppo. Un approccio pragmatico in quattro fasi si rivela efficace per i team che partono da una codebase non ancora misurata.

Fase 1: Stabilire un punto di riferimento. Prima di apportare qualsiasi modifica, esegui un'analisi statica completa del codice sorgente. Registra i valori correnti per la distribuzione della complessità ciclomica, l'indice di manutenibilità per file, la densità dei difetti, la copertura e il tasso di duplicazione. Questa baseline rappresenta il punto di partenza rispetto al quale verranno confrontate tutte le misurazioni future. Senza una baseline, non è possibile stabilire se le modifiche stiano migliorando o peggiorando la qualità.

Fase 2: Definire le soglie. Definisci soglie accettabili per ogni parametro, appropriate al contesto. Un'applicazione web commerciale e un dispositivo medico critico per la sicurezza hanno soglie appropriate diverse. Documenta queste soglie negli standard di qualità del progetto e rendile visibili a tutto il team.

Fase 3: Integrazione nel processo CI/CD. Configura la pipeline CI per calcolare le metriche chiave a ogni commit o pull request. Segnala le modifiche che portano una metrica al di fuori del suo intervallo accettabile. Blocca le fusioni che introducono nuovo codice con complessità ciclomica superiore alla soglia, che riducono la copertura al di sotto della soglia o che introducono risultati critici nell'analisi statica. In questo modo, le soglie delle metriche si trasformano da linee guida in standard obbligatori.

Fase 4: Analizzare le tendenze, non le istantanee. Una singola misurazione è informativa; un trend, invece, permette di intervenire. Un aumento della frequenza di modifica del codice in un modulo specifico, una diminuzione della copertura del codice nel corso del ciclo di rilascio o un calo dell'indice di manutenibilità per un file specifico segnalano tutti problemi che una misurazione istantanea potrebbe non rilevare. È opportuno analizzare i trend delle metriche a ogni retrospettiva di sprint.

Metriche di qualità del codice in contesti aziendali, agili e critici per la sicurezza

Metriche di qualità del codice nello sviluppo agile

I team Agile si trovano ad affrontare una sfida specifica con le metriche di qualità del codice: l'enfasi sulla consegna di software funzionante in cicli brevi può creare la pressione di rilasciare il prodotto prima che i problemi di qualità siano risolti. La soluzione non è abbandonare le metriche, ma includerle nella definizione di "fatto". Una storia non è completa quando la funzionalità funziona; è completa quando la funzionalità funziona e il nuovo codice soddisfa le soglie di qualità del team.

Gli indicatori anticipatori nei contesti agili, ovvero le metriche che prevedono i problemi futuri prima che si manifestino, includono il tasso di ricambio del codice, il nuovo debito tecnico introdotto per sprint e l'andamento del numero di risultati dell'analisi statica per rilascio. Gli indicatori ritardati, ovvero le metriche che misurano i risultati già ottenuti, includono la densità dei difetti riscontrati nei test, il tempo dedicato alla manutenzione rispetto al tempo impiegato per le nuove funzionalità e il tasso di incidenti in produzione per rilascio.

Qualità del codice per la due diligence tecnica

La due diligence tecnica nelle operazioni di fusione e acquisizione, nella selezione dei fornitori e nei processi di acquisizione di sistemi richiede una valutazione strutturata della qualità del codice sull'intera codebase. Le metriche più importanti in questo contesto sono:

• Distribuzione dell'indice di manutenibilità: quale percentuale del codice sorgente rientra nelle zone rossa, gialla e verde
• rapporto di debito tecnicoQual è il costo stimato della bonifica rispetto al costo di sviluppo?
• Densità dei difetti: quanti difetti noti esistono per KLOC e come si confronta questo dato con i parametri di riferimento del settore
• Copertura di prova: quale percentuale del codice sorgente è coperta da test automatizzati e a quale livello (riga, ramo, condizione)
• Salute dipendente: quante dipendenze esterne esistono, quante sono obsolete o abbandonate e quanto è profondamente accoppiata l'architettura
• Duplicazione del codice: quale frazione del codice sorgente è duplicata, indicando il rischio di manutenzione

Come esaminato nel contesto di analisi d'impatto per la valutazione del codice aziendaleComprendere non solo il punteggio di ciascun componente in termini di metriche di qualità, ma anche come i componenti dipendono l'uno dall'altro, è essenziale per una due diligence accurata: un modulo di bassa qualità isolato può comportare costi di riparazione gestibili, mentre lo stesso modulo al centro di un grafo di dipendenze complesso rappresenta un rischio molto maggiore.

Qualità del codice nelle applicazioni critiche per la sicurezza e nel settore fintech.

Le applicazioni critiche per la sicurezza nei settori aeronautico, automobilistico, dei dispositivi medici e del controllo industriale richiedono standard di qualità del codice che vanno oltre quelli tipici del software commerciale. Differenze principali:

• I limiti di complessità ciclomica sono generalmente fissati a 10 o inferiori, e le eccezioni richiedono una giustificazione formale.
• I requisiti di copertura utilizzano MC/DC (copertura in base a condizioni/decisioni modificate) anziché la copertura di linea o di filiale.
• L'analisi statica deve essere eseguita con strumenti certificati e le violazioni devono essere documentate e risolte o formalmente accettate
• Il ricambio di codice viene monitorato come indicatore di sicurezza: tassi di modifica elevati nei moduli critici per la sicurezza attivano ulteriori revisioni e riconvalide.

Le applicazioni fintech subiscono pressioni simili da parte dei quadri normativi. Lo standard PCI DSS richiede standard di codifica sicuri e processi di revisione del codice. La conformità SOX per i sistemi di reporting finanziario richiede una tracciabilità documentata dai requisiti, passando per il codice, fino ai test. Le metriche di qualità del codice forniscono la prova oggettiva del funzionamento di questi processi: i report di copertura dimostrano l'esistenza dei test, i report di analisi statica dimostrano che sono stati verificati i modelli di vulnerabilità noti e i report di complessità dimostrano che i revisori sono stati in grado di valutare ragionevolmente il codice.

Metriche di qualità del codice per linguaggio

Metriche di qualità del codice Python può essere calcolato utilizzando radon (indice di complessità ciclomica e manutenibilità), pylint (code smells e violazioni di stile), coverage.py (copertura dei test), bandit (problemi di sicurezza) e mypy or pyright (correttezza del tipo). L'indice di manutenibilità in radon Utilizza una formula di Halstead modificata e calibrata per Python. Il voto A è superiore a 20, il voto B è compreso tra 10 e 20, il voto C è inferiore a 10.

Qualità del codice RPG Su IBM i sono necessari strumenti specializzati perché gli strumenti standard per la misurazione della qualità non analizzano la sintassi RPG. SMART TS XL Fornisce analisi della complessità ciclomica, del numero di righe di codice e delle dipendenze per i programmi RPG, il che è particolarmente utile per le aziende che utilizzano IBM i e gestiscono grandi codebase legacy, dove in precedenza era impossibile automatizzare la misurazione della qualità.

Metriche di revisione del codice

La revisione del codice è un'attività di controllo qualità la cui efficacia può essere misurata:

• Rivedere la copertura: percentuale di codice confermato che ha superato una revisione formale prima dell'unione
• Difetti riscontrati in base alla recensione: il numero di difetti rilevati durante la revisione rispetto alla dimensione del changeset esaminato
• Tempi di elaborazione della revisione: il tempo che intercorre tra l'apertura di una pull request e la sua revisione e unione
• Tasso di risoluzione dei commenti di revisione: la percentuale di commenti di revisione che si traducono in una modifica del codice rispetto a quelli che vengono ignorati

I team ad alte prestazioni mostrano in genere una copertura di revisione superiore al 90%, una media di difetti riscontrati per revisione compresa tra 1 e 3 ogni cento righe esaminate e tempi di risposta brevi. Le metriche di revisione aiutano a identificare se la revisione del codice funziona come un controllo di qualità o come una mera formalità.

Monitoraggio continuo della qualità del codice

Una misurazione una tantum della qualità del codice è significativamente meno utile del monitoraggio continuo. La qualità del codice non è una proprietà fissa di una codebase; cambia a ogni commit. Una codebase che oggi ha una buona qualità può deteriorarsi notevolmente in tre sprint di sviluppo accelerato se le metriche di qualità non vengono monitorate costantemente.

Un monitoraggio continuo ed efficace della qualità del codice include:

• Calcolo della metrica per ogni commit: complessità ciclomica e risultati dell'analisi statica calcolati ad ogni spinta
• dashboard di tendenza: rappresentazioni visive dei parametri chiave nel tempo, aggiornate giornalmente o per ogni rilascio
• Controlli di qualità in CI/CD: applicazione automatizzata di soglie minime per le metriche che influiscono sulla manutenibilità, sulla sicurezza e sul rischio di difetti
• Rilevamento della regressione: avvisa quando una metrica si muove significativamente nella direzione sbagliata tra le release

Gli indicatori principali per il miglioramento della qualità del codice, ovvero i segnali che prevedono se la qualità sarà migliore o peggiore nella prossima release, sono la direzione del trend di copertura, la nuova complessità introdotta per sprint e il rapporto tra i code smell risolti e quelli introdotti. Quando questi indicatori si muovono nella giusta direzione, la qualità migliorerà. Quando non lo fanno, il deterioramento è prevedibile prima ancora che si verifichi completamente.

Come SMART TS XL Misura e migliora la qualità del codice

SMART TS XL calcola l'insieme completo delle metriche di qualità del codice descritte in questo articolo su ogni linguaggio e piattaforma nell'ambiente di sviluppo: COBOL, JCL, Java, .NET, Python, JavaScript, TypeScript, RPG, SQL e altri. Mentre la maggior parte degli strumenti di qualità opera su un singolo linguaggio alla volta, SMART TS XL Crea un modello di qualità unificato dell'intero sistema, rendendo possibile confrontare la qualità tra diverse lingue, monitorare le metriche a livello di sistema anziché a livello di file e identificare problemi di qualità tra i componenti che gli strumenti per singola lingua non sono in grado di rilevare.

Per le organizzazioni aziendali con codebase ampie e multilingue, analisi statica del codice capacità di SMART TS XL fornisce la misurazione di base necessaria per la dovuta diligenza tecnica, la pianificazione della modernizzazione dei sistemi legacy e il miglioramento continuo della qualità. mappatura delle dipendenze Questa capacità estende la valutazione della qualità alle problematiche strutturali: quali componenti sono maggiormente dipendenti, quali modifiche hanno il raggio d'azione più ampio e quali aree del codice sorgente rappresentano il rischio di manutenzione più elevato quando le metriche di qualità vengono combinate con la centralità delle dipendenze.

SMART TS XLLe metriche di qualità del codice si integrano con le pipeline DevOps tramite la sua API, abilitando controlli di qualità a livello di CI/CD. Quando un commit introduce una funzione con complessità ciclomica superiore a una determinata soglia, o riduce la copertura al di sotto del minimo configurato, o introduce un risultato critico nell'analisi statica, la pipeline può interrompere la build con una diagnostica specifica che indica allo sviluppatore esattamente cosa è stato misurato e perché la soglia non è stata raggiunta. Questo sposta il controllo della qualità dagli audit post-rilascio al feedback in fase di sviluppo, riducendo il costo dei problemi di qualità individuandoli nel momento in cui sono più economici da risolvere.

La qualità del codice è una disciplina di squadra, non un report.

Il valore delle metriche di qualità del codice è determinato interamente da come i team le utilizzano. Un report trimestrale sulla qualità del codice, se nessuno interviene, è peggio di nessun report, perché crea l'illusione che la qualità venga gestita mentre il codice si deteriora incontrollato. Le metriche diventano preziose quando guidano azioni specifiche: quando un picco di complessità ciclomica in una nuova funzione innesca una discussione sul refactoring prima che la funzione venga unita al codice sorgente, quando un calo della copertura in un modulo innesca uno sprint di test, quando una crescente densità di difetti in un componente specifico innesca una revisione formale della progettazione di quel componente.

Costruire questa cultura richiede di rendere visibili le metriche al momento giusto, durante lo sviluppo e non dopo il rilascio, e di collegarle a impegni concreti del team. I team che analizzano l'andamento della qualità del codice a ogni retrospettiva di sprint, che includono soglie di qualità nella definizione di "fatto" e che trattano una regressione delle metriche con la stessa serietà di una regressione delle funzionalità, creano codebase che costano meno da mantenere e producono meno incidenti in produzione nel tempo. La misurazione è il punto di partenza. La disciplina è ciò che produce il risultato.