arrow for title

Le best practice sono il faro da seguire

21 Dic, 2020 Sviluppo
Le best practice sono il faro da seguire

Quanto è importante seguire le best practice? Nello sviluppo è fondamentale, per produrre software di alta qualità. Ti spiego perché in questo articolo.

Best practice, standard e processi

Se faccio un salto nel passato e provo a pensare ai miei primi progetti, posso trovare una lunga lista di errori che ho commesso e che mi hanno permesso di formarmi.

Lo sviluppo del software è un’attività che, per fortuna, è ormai corredata da numerose best practice e moltissimi standard, concordati da sviluppatori autorevoli, e non solo. Sono tantissimi i linguaggi di programmazione, tantissimi i pattern che vengono usati e tantissime le tecniche per risolvere problemi con tecnologie digitali.

Per fortuna, tutto questo ecosistema è controllato da alcune regole di buona condotta che chi produce software di qualità segue molto attentamente.

Ovviamente anche noi, come molti altri team, abbiamo definito il nostro processo e abbiamo le nostre linee guida, che funzionano per il flusso che abbiamo stabilito internamente, senza mai trasgredire le best practice generali.

best practice 20tab

In questo articolo voglio riportare alcune di queste regole che io e il mio team utilizziamo durante il processo di implementazione. Iniziamo!

Come si può vedere dalla figura in alto, il processo di sviluppo è un’azione ciclica e continua. 

Scrivere codice che non è stato ancora analizzato o, peggio, che non è stato ancora richiesto, potrebbe essere una gran perdita di tempo. Potrebbe essere anche dannoso, introducendo degli errori non previsti

Tutto questo richiede uno sforzo ulteriore, per effettuare i test e la manutenzione. Per cui è molto importante attenersi al requisito. 

Molto spesso capita di scrivere funzionalità che riportano codice molto simile a quello che abbiamo già scritto da qualche altra parte nel nostro progetto. 

È molto importante saper individuare quelle porzioni di codice e incapsularle in moduli o funzioni riutilizzabili. Anche questo ci evita di introdurre potenziali nuovi bug.

I due punti precedenti hanno già introdotto il concetto di test. Scrivere i test e scrivere il codice dell’applicazione sono due facce della stessa medaglia: se vogliamo bene al nostro codice, allora i test ne fanno parte. Ne ho parlato anche in un altro articolo.

L'approccio più adatto è quello del TDD (Test Driven Development): scrivere i test ancora prima di scrivere la funzionalità ci mette nelle condizioni di analizzare a fondo il requisito, e quindi scriveremo solo il codice necessario (rispettando il primo punto).

Scrivere codice senza test è pura incompetenza ed è anche pericoloso, un po’ come passare col rosso ad un semaforo.

Immaginiamo un software che gestisce, ad esempio, la guida automatica di un’automobile. O, ancora, un software che gestisce il pannello di controllo di un aeroplano. Se questo codice non fosse testato, questo potrebbe portare a gravissime conseguenze. 

In effetti non scrivere i test è un grosso atto di irresponsabilità.

Il code coverage è sicuramente una delle metriche più importanti per definire quante linee di codice sviluppato sono attraversate dai test automatici. 

Attenzione, però: se il code coverage è alto, questo non significa aver scritto bene i test o aver messo il codice in sicurezza.

Avere questa metrica sotto controllo ci permette di valutare se il codice è in pessime condizioni, quando il coverage è molto basso. Ma, se osserviamo in modo diligente il punto precedente, allora non dovremo preoccuparci di questo.

D’altro canto, voglio soffermarmi ancora sul concetto di code coverage per tutti quelli che usano questa metrica come linea guida, riportando un esempio.

Se abbiamo una funzione che deve elaborare dei dati, possiamo scrivere un test che chiami quella funzione e controllare semplicemente il buon esito della chiamata: questo test fa sì che la copertura sia garantita, ma non ci assicura che l’algoritmo che è implementato al suo interno faccia ciò che ci aspettiamo. 

Per questo è molto importante definire tutti gli scenari possibili e i relativi input del test. E aspettarsi il giusto output dopo la sua chiamata. 

Questo punto si appoggia un po’ a tutti i punti precedenti. 

Scrivere il codice necessario per soddisfare i requisiti, e scrivere il test per verificarne il corretto funzionamento, dovrebbe essere l’approccio da seguire. 

Se ci atteniamo a queste regole, il codice che scriveremo sarà il minimo indispensabile. Inoltre, è fondamentale prestare attenzione alla qualità del codice prodotto e, quindi, revisionare di volta in volta ciò che è stato implementato, per minimizzare la quantità di codice dei nostri algoritmi e ottimizzarne il funzionamento e le performance.

E il punto precedente ci porta direttamente a questo. 

Se avessimo centinaia di righe di codice in una funzione, scrivere un buon test sarebbe quanto meno laborioso. Invece, scrivere un test per una piccola porzione di codice risulterà molto semplice.

A volte ci tocca correre, e la fretta non è mai una buona consigliera. 

È importante non tralasciare l’ottimizzazione del codice rilasciato quando sappiamo che non è stato scritto nel modo migliore: dedicare del tempo al refactoring ci evita brutte sorprese quando le cose si mettono male. 

Ottimizzare delle query al database, scrivere algoritmi più semplici e chiari, ridurre il numero di linee di codice superfluo, rendere il codice più comprensibile, sono tutte cose che possono essere fatte anche in un secondo momento, se al momento del rilascio non ne abbiamo avuto la possibilità.

Ovviamente, se lavorassimo con la fretta perderemo sicuramente la qualità che vogliamo ottenere dal nostro lavoro. 

A questo punto dovremmo aver capito quanto è importante scrivere buon codice accompagnato da una suite di test. 

Inoltre, in un processo moderno di sviluppo software è fondamentale creare un processo per le build e il setup della nostra applicazione, che possa essere automatico, funzionante e che abbia la giusta documentazione per chiunque debba interagirvi.

Questo ci permetterà di essere più rapidi nell’introdurre nuovi programmatori nel team e ridurrà drasticamente la possibilità dell’errore umano da distrazione durante le installazioni.

Anche quando rilasciamo il software siamo soggetti ad errore umano. E, anche in questo caso, avere un buon processo automatizzato e stabile ci eviterà enormi perdite di tempo. Ho approfondito questo argomento proprio qui.

 

Ovviamente tutte queste pratiche sono il frutto di tanto buon senso, che dovrebbe essere la prima cosa da tenere sotto controllo quando si sviluppa un software.

Raffaele Colace

contattaci

Portiamo l'innovazione nel tuo progetto, senza sprechi di tempo e denaro.

Prendiamo un appuntamento!

Blog

Potrebbe interessarti anche: