Nella presentazione su infoQ Bryan Helmkamp, fondatore e CEO di Code Climate, discute di alcune intuizioni sulla qualità del codice derivate dall'analisi statica di oltre mille miliardi di linee di codice al giorno.

Cos'è la qualità del codice?

Il concetto di «qualità del codice» non è così ben definito. Raccogliendo le opinioni da molti team di sviluppo emerge che scrivere codice di qualità ha a che fare con aggettivi come:

• semplice;
• chiaro: i nomi utilizzati per variabili, e simili, aiutano a comprendere il codice;
• ben testato e senza bug;
• sottoposto a refactoring;
• documentato: aspetto controverso perché alcuni team hanno scelto di misurare la qualità includendo la presenza di documentazione, altri team si limitano ad una documentazione di alto livello e non considerano la documentazione di alto livello un indice di qualità del loro software;
• estensibile: altro aspetto controverso perché da un lato alcuni team sono interessati alla facilità di costruire sul codice da loro sviluppato, mentre altri team si interrogano sull'importanza di costruire codice estensibile prima che si presenti una qualunque necessità di estensione;
• veloce: tipicamente si considerano le prestazioni a runtime;

Esistono differenti modi per migliorare la qualità del codice, per questo è importante che ogni componente del proprio team concordi su come si intende lavorare. Per enfatizzare questo concetto Helmkamp cita uno sconosciuto che scrisse:

Qualsiasi codice meno decomposto del mio è una gran confusione. Qualsiasi codice più decomposto del mio è sovra-ingegnerizzato.

Qual'è il modo migliore per misurare la complessità del codice?

by Thom Holwerda

A parte la battuta sui WTF/s, nel contesto dell'analisi statica del codice sono particolarmente efficaci:

• complessità ciclomatica: numero di cammini linearmente indipendenti attraverso il grafo di controllo di flusso;
• metrica ABC: dove ABC sta per numero di Assegnazioni, Branches (diramazioni), Condizioni; è calcolata come $\sqrt{A^2+B^2+C^2}$;
• numero di linee di codice (LOC).

Helmkamp preferisce la LOC sia perché è strettamente correlata con le altre metriche sia perché è semplice da calcolare. Ad ogni modo, indipendentemente dalla metrica scelta, è importante dire agli sviluppatori come essa è calcolata, perché gli sviluppatori hanno bisogno di sapere cosa fare dal punto di vista pratico per migliorarla. Inoltre raccomanda di scegliere la metrica più congeniale al proprio team; alcuni team, infatti, “pensano” in termini di LOC, altri in numero di metodi per classe (e simili), altri team in altri modi ancora.

Perché i progetti più vecchi sono più difficili da manutenere?

Helmkamp identifica due motivi principalmente responsabili nella difficoltà di manutenzione di software con vari anni di vita.

Il primo è il circolo vizioso auto-referenziale pressione → deterioramento → ritardo. Con il trascorrere del tempo un corpo di codice è sottoposto a varie “pressioni” che hanno l'effetto di deteriorarne la qualità. Tale deterioramento comporta ritardi che a loro volta generano ulteriori pressioni. L'intuizione di Helmkamp su questo punto è che anche la qualità del codice è un obiettivo che cambia nel tempo: ciò che si considerava di qualità all'inizio del progetto non è detto che sia di qualità anche quando il codice è notevolmente cambiato rispetto ai primi rilasci.

Il secondo è la deriva tecnica, strettamente correlata al debito tecnico. Con il passare del tempo il business cambia, per cui il dominio del business tende a divergere da quello per cui il codice era stato inizialmente progettato e sviluppato. Per contenere tali fenomeni si ricorre a refactoring occasionali ed impegnativi, oppure ad approcci iterativi con refactoring più frequenti e meno impegnativi (Una regola dei Boy Scouts dice: lascia il campeggio in una condizione migliore di come l'hai trovato.).

Qual'è la dimensione ottimale di una pull request?

Uno studio condotto da Cisco mostra come il numero di difetti rilevati da una revisione del codice cali con il crescere del numero di linee di codice sottoposte a revisione:

Si tratta di una misura dell'efficacia umana nel rilevare difetti durante una revisione del codice che dura dai 60 ai 90 minuti. Lo studio individua che la dimensione ottimale di una pull request va dalle 200 alle 400 linee di codice.

L'analisi statica di codice è normalmente eseguita da software che può essere facilmente integrato in sistemi di continuous integration. L'efficacia di tali processi nel rilevare difetti è indipendente da quante linee di codice sono state committate.

Ad ogni modo Helmkamp ritiene che i risultati migliori per incrementare la qualità del codice si ottengono affiancando le usuali revisione del codice eseguite da esseri umani all'analisi statica automatizzata.

Quando del codice scadente non è un problema?

Helmkamp individua tre casi in cui del codice di scarsa qualità non è un problema.

Un primo caso è di carattere gestionale: le persone del business non sono disposte ad investire risorse in qualcosa che non si traduca direttamente in valore per gli affari. Chiaramente il debito tecnico affligge anche i software sviluppati in tali ambienti, ma finché i costi di rifare un altro software di scarsa qualità rimangono accettabili per le persone del business allora non c'è motivo di lavorare sulla qualità del codice (che rimane percepita come un lusso).

Un secondo caso è condizionato dall'incertezza su alcuni requisiti. In tal caso potrebbe essere conveniente progettare il software affinché il componente che implementa i requisiti nebulosi sia più facilmente sostituibile che non evolvibile. In altre parole i componenti che ci si aspetta debbano essere gettati via potrebbero rimanere di scarsa qualità.

Un ultimo caso è quello di un omega mess, un termine coniato da un amico di Helmkamp, che indica una parte di codice che sia:

• di scarsa qualità;
• molto estesa;
• con molte dipendenze interne (intricata);
• che non cambia;
• che non invoca nessuna parte del nostro codice;
• che non è invocata direttamente dal nostro codice;
• che è invocata indirettamente dal nostro codice solo attraverso un componente che funge da interfaccia;

Qual'è il peggior nemico di un codice di qualità?

Helmkamp è affascinato da un circolo vizioso, identificato da David Peterson, nel quale sviluppatori con buone intenzioni finiscano inevitabilmente col produrre codice di scarsa qualità:

Helmkamp è consapevole che motivazioni psicologiche come apatia (perché il codice potrebbe non interessare a nessuno) o frustrazione (perché magari i requisiti cambiano continuamente) incidano sulla qualità del codice ma è convinto che il nemico principale del codice di qualità sia la paura di cambiare il codice esistente. Per ridurre tale paura identifica alcune pratiche:

• test automatici;
• metriche operazionali;
• revisione del codice;
• analisi statica del codice;
• pair programming;

che possono aiutare, anche se non eliminano del tutto il problema.