L’importanza della qualità nello sviluppo del software

Questo è il post #12 di 12 nella serie “Fondamenti di Programmazione 101”

Ci sono molti aspetti da considerare quando parliamo di qualità del codice. Per esempio, possiamo prendere in considerazione aspetti come l’efficienza del codice che riguarda quanto velocemente il nostro codice viene eseguito o che non sprechi risorse come la memoria.

Definiamo cosa si intende con qualità del codice

Modello di qualità CISQ

Il consorzio per la qualità del codice (Consortium for Information Software Quality) ha definito 5 regole che possono essere usate per misurare la qualità del codice e sono:

• Affidabilità (Reliability): l’Affidabilità misura il livello di rischio e la probabilità di fallimenti. Inoltre misurerà i bugs che verranno introdotti nel codice esistente quando viene aggiornato o modificato. Lo scopo principale di questa regola è quello di ridurre il tempo nel quale l’applicazione non possa essere eseguita a causa di errori gravi.

• Efficienza delle performance (Performance Efficiency): quando un applicazione è in esecuzione, la sua velocità di esecuzione dipende da come il codice è stato scritto e strutturato. Misurare l’efficienza, a livello di codice, aiuterà sia i tempi di risposta in generale, così come la capacità d’identificare i potenziali rischi di un applicazione che necessita di processare i dati ad alta velocitá che fallisce perché non riesce a processarli abbastanza velocemente.

• Sicurezza (Security): la regola di sicurezza misurerà la probabilità di potenziali rischi di sicurezza a causa di una pratica di programmazione non adeguata.

• Manutenibilità (Maintainability): questa regola fa riferimento la manutenibilità del codice e si divide in 2 sotto categorie:

• Adattabile (Adaptable): un codice è adattabile se è abbastanza flessibile da potersi adattare facilmente a cambi nei requisiti

• Portabile (Portable): codice che può essere usato su piattaforme differenti come per esempio, sistemi operativi differenti

• Trasferibile (Transferable): codice che può essere trasferito da un team di sviluppo a un altro

• Dimensione (Size): la dimensione non viene classificata come un attributo di qualità ma la dimensione del codice può avere un impatto sulla manutenibilità del codice stesso. Più codice abbiamo e più sarà difficoltoso da ispezionare, capire e seguirne la logica.

Pensiamo sempre alla leggibilità

Il codice che scriviamo non verrà solo eseguito da un computer, noi stessi e anche altre persone ci lavoreranno, lo leggeranno e lo modificheranno e per questo, è essenziale che il codice sia, il più possibile, leggibile e comprensibile.

Vediamo alcune regole per rendere il nostro codice più leggibile e facile da capire.

Usiamo commenti e documentazione in maniera saggia

Quando scriviamo codice, abbiamo la necessita di capire cosa stiamo facendo e perché lo stiamo facendo. Quando ci capita di ritornare sul codice settimane o mesi dopo, l’intento iniziale è spesso non così chiaro e non ci ricordiamo le motivazioni che ci hanno spinto a prendere le decisioni che abbiamo preso.

Aggiungere dei commenti nelle parti di codice più astruse e misteriose può dare un grande aiuto a noi stessi nel futuro e/o ai nostri colleghi quando si troveranno a dover modificare il codice.

I commenti, però, possono anche aggiungere inutile “rumore” che può distrarci dal punto più importante quindi è imperativo che impariamo a usarli in maniera coscienziosa come per esempio, evitare di commentare parti di codice che sono ovvie.

Commentare metodi è sempre una buona idea, possiamo aggiungere una breve descrizione riguardo l’intento della funzione così come descrivere i parametri e i valori ritornati dalla funzione stessa. Un ulteriore beneficio è che i moderni IDEs possono ispezionare il codice e fornire informazioni all’interno dell’IDE stesso. Importante notare a riguardo, che linguaggi di programmazioni diversi possono utilizzare diverse convenzioni sul formato che dobbiamo utilizzare per scrivere dei commenti compliant per il linguaggio specifico.

Usiamo nomi come documentazione

È importante dare nomi che trasmettono l’intento quando li assegniamo a variabili e metodi, un nome ben scelto e ponderato è sicuramente più utile di un nome non adeguato anche se abbiamo dei commenti a descriverlo. Tempo speso a scegliere un nome adeguato non è mai tempo perso!

Leggiamo il codice scritto da altri

Specialmente per un programmatore novello, uno dei modi migliori per scrivere buon codice è quello di leggere codice scritto da programmatori più esperti. Un ottima fonte di lettura possono essere i progetti open source sviluppati da programmatori esperti e il loro codice è gratuitamente disponibile on-line.

Prendiamo un progetto open source, preferibilmente nel linguaggio di programmazione che vogliamo imparare o in cui vogliamo migliorare. Sicuramente, all’inizio, può intimidire visto che questi progetti possono avere centinaia e migliaia di linee di codice. Prendete il tempo necessario per capire la struttura delle cartelle che compone il progetto e iniziate a leggere piccole porzioni di codice.

Questo vi aiuterà a capire come un programmatore esperto struttura la gerarchia di cartelle e particolari convenzioni che utilizza nella scrittura nel codice. Ovviamente non tutti i programmatori senior scriveranno codice di alta qualità ma molti lo faranno quindi potrete trovare diversi spunti di riflessione interessante.

Rimuoviamo codice superfluo o non necessario

Una pratica di cui dovrete assolutamente diventare padroni è quella del rimuovere codice superfluo cioè codice che non modifica l’ output del programma ma viene comunque eseguito.

Best practices per codice di qualità

Quando scriviamo codice, ci sono alcune cose che dobbiamo sempre tenere a mente per rendere il nostro codice di qualità:

• Limitare la lunghezza delle linee
  Linee lunghe non sono mai una buona idea. Una regola generica è che se una linea è più lunga della lunghezza dello schermo allora, probabilmente è troppo lunga. Se necessario, spezziamo la linea su più linee. La cosa importante è sempre la regola che il nostro codice deve essere leggibile. Tutti gli editor moderni forniscono funzionalità per formattare il codice in modo da rispettare regole che si possono settare come configurazioni dell’IDE o di tools di aiuto che possiamo usare nei nostri progetti.

• Limitare la lunghezza delle nostre funzioni/metodi
  In generale, una funzione deve fare una sola cosa e deve essere piccola. Funzioni lunghe sono difficoltose da leggere e non è facile capirne la logica, è sempre meglio spezzare lunghe funzioni in funzioni più piccole assegnando dei nomi chiari che ne trasmettano il chiaro intento.

• Scrivere funzioni piccole di qualità è un arte e come tale ci vuole tempo per impararla ma se non si inizia, non si riuscirà mai!

• Evitare profonde nidificazioni
  Alle volte possiamo essere tentati dallo scrivere molteplici IF statements o cicli dentro cicli. Questa non è mai una buona idea in quanto rende il nostro codice veramente difficile da leggere e non è facile capire quale blocco di codice fa parte di cosa. Evitatelo!

• Usiamo il DRY principle
  Il principio DRY (che sta per Don’t Repeat Yourself) è stato per la prima volta formulato da Andy Hunt e Dave Thomas. Eccovi la definizione originale:

  Every piece of knowledge must have a single, unambiguous, authoritative representation within a system

Il significato è che non ci dovrebbe essere codice uguale o simile, ripetuto più di una volta, all’interno del nostro sistema. Un chiaro esempio di violazione di questo principio fondamentale è quando facciamo copia e incolla di codice da un punto nel nostro codice a un altro.

Questo dovrebbe SEMPRE essere evitato! Usiamo convenzioni di codice
Molti linguaggi di programmazione hanno delle convenzioni su come scrivere il codice. Queste raccomandazioni spaziano da come organizzare i files, che tipo d’indentazione usare, il formato dei commenti e convenzioni sulla notazione da usare quando assegniamo nomi a variabili e funzioni.

Puntualizziamo che queste non sono regole inviolabili ma solo raccomandazioni e l’idea principale che c’è dietro è, se tutti i programmatori che usano un dato linguaggio utilizzano delle convenzioni comuni allora il codice sarà simile per tutti.
Come conseguenza c’è che utilizzando le stesse convenzioni ci verrà più facile ispezionare e leggere il codice. Imparare le convenzioni di una dato linguaggio di programmazione è uno step importante per qualunque sviluppatore software.

Convenzioni quando usiamo dei nomi
Una naming convention è rappresentata da un insieme di regole per formattare i nomi di variabili, tipi, funzioni e altre entità presenti in un linguaggio di programmazione. Una naming convention non riguarda che nome diamo alle cose ma che formattazione usiamo quando diamo nomi alle cose, riguarda se utilizziamo lettere maiuscole o minuscole, riguarda come decidiamo di formattare nomi che sono composti da più di una parola.
Vediamo alcuni dei tipi di formattazione più utilizzati:

• Camel Case
  In camel case ogni parola, in una parola costituita da più parole, ha una lettera iniziale maiuscola a parte la prima che usa una lettera minuscola. Per esempio, se volessimo salvare il valore di quanti litri di benzina abbiamo messo nella nostra moto, in camel case potremmo usare come nome della variabile litriDiRifornimento
• Pascal Case Pascal case è simile a Camel case, l’unica differenza è che anche la prima lettera è in maiuscolo. Quindi l’esempio precedente diventerebbe LitriDiRifornimento.
• Snake Case
  In Snake case tutte le lettere sono in minuscolo e ogni parola viene divisa da un underscore. L’esempio precedente diventa litri_di_rifornimento.

Ovviamente ci sono tantissime altre considerazioni da fare e cose da imparare quando si tratta l’argomento della qualità del software ma questi che abbiamo analizzato in questo articolo sono alcune fra le cose fondamentali che ogni sviluppatore dovrebbe tenere in considerazione e averne conoscenza.
Se volete diventare dei bravi sviluppatori, sforzatevi di scrivere del codice di qualità e come già detto precedentemente, questa è una cosa che richiede tempo ed esperienza quindi più che una competenza da acquisire è un percorso da intraprendere.