La qualità del codice

Nascondi

Quella che segue è una trascrizione automatica dell'episodio.

Pensieri in codice. Idee dal mondo del software, a cura di Valerio Galano. Salve a tutti e bentornati su Pensieri in codice, il podcast in cui parliamo di idee prese dal mondo del software, di internet e della programmazione. Nell’episodio di oggi mi piacerebbe parlarvi di un argomento che mi sta particolarmente a cuore e che sono convinto che debba stare a cuore ad ogni buon programmatore. Qualcosa che fin troppo spesso viene sacrificato in nome di altre priorità considerate più importanti, cioè la qualità del codice. Per capire prima di tutto cosa significa qualità del codice e perché è fondamentale cercare di mantenerla il più alta possibile quando si programma, dobbiamo tenere a mente un concetto molto importante e cioè che il mondo del software ci ha abituato all’idea di aggiornamento. Se pensiamo ai nostri pc o ai nostri smartphone ad esempio, ci rendiamo conto che siamo abituati ad aspettarci aggiornamenti molto frequenti, sistemi operativi, programmi, app, tutto si aggiorna con cadenza mensile, settimanale o addirittura giornaliera. La correzione dei bug, l’implementazione di nuove funzioni che causano un continuo susseguirsi di nuove versioni da installare sono cose che ormai non solo sopportiamo ma anzi ci aspettiamo e vengono percepite come qualcosa di positivo. Quasi che la loro assenza faccia apparire quel programma o quell’app che non si aggiorna frequentemente come se fosse stata abbandonata dai propri sviluppatori. E quindi per questo motivo che chi sviluppa software deve essere ben conscio del fatto che la propria codebase e cioè l’insieme di tutte le librerie, le istruzioni, i metodi, le funzioni che vanno a comporre il proprio software è un qualcosa che deve restare in un continuo stato di evoluzione e sarà interessata giorno dopo giorno da modifiche, correzioni, implementazioni eccetera. D’altra parte però qualsiasi programmatore con qualche anno di esperienza alle spalle sa bene che effettuare una modifica o un’implementazione al codice di un software non è sempre qualcosa di così semplice. In effetti ci sono casi in cui per effettuare una modifica all’apparenza semplice si è costretti a spendere molto più tempo di quanto in realtà necessario. Esistono casi in cui modifiche che normalmente dovrebbero richiedere qualche ora rischiano di portar via anche giorni per essere completate e questi tipicamente sono i casi in cui ci si trova ad operare su di un codice cattivo, un codice sporco. Già perché è proprio in questo che si distingue un codice di scarsa qualità, non nei bug, non nelle scarse funzionalità. I bug si correggono, le funzionalità assenti o incomplete si implementano ma un codice di scarsa qualità invece ha proprio la caratteristica di rallentare il lavoro dello sviluppatore. Estendere, modificare o correggere un codice cattivo è un lavoro difficile, lungo e molto spesso poco proficuo. E da dove viene fuori questo codice di scarsa qualità? La prima idea che potrebbe venire in mente è che esso sia frutto di incompetenza o di inesperienza. In effetti entrambe queste componenti possono avere un peso nella qualità del codice prodotto. Tuttavia io mi riferisco in particolare a codice qualitativamente scarso sviluppato però da programmatori con buone conoscenze del progetto e del linguaggio e soprattutto con una certa esperienza. In questo caso la vera causa che ci porta ad avere una codebase disordinata e un pessimo codice è semplicemente la fretta. Sì perché noi programmatori abbiamo attività da svolgere e scadenze da rispettare, dobbiamo sviluppare nuove funzionalità, dobbiamo correggere i bug e spesso questo ci porta ad avere la percezione che non ci sia tempo sufficiente per fare tutto. Da qui la conseguenza è quella di lavorare in modo approssimativo e frettoloso ed ecco che il codice che viene fuori è di scarsa qualità. Quello che può derivare da questo processo e vi assicuro che l’ho visto accadere più di una volta è una drastica diminuzione della produttività del team di sviluppo. Sì perché se ogni volta che devo apportare una modifica al mio codice esso risulta problematico, mi ostacola e mi porta a perdere tempo prezioso, io sarò costretto a correre per portare a termine la mia attività e questo mi indurrà a produrre altro codice di cattiva qualità. Una volta entrati in questo circolo vizioso poi si arriverà al punto in cui le mie risorse o quelle del mio team non saranno più sufficienti per soddisfare le necessità. Se arrivati a questo punto non avremo ancora intrapreso una strada verso il miglioramento della qualità del nostro codice e a questo punto già sarà molto difficile visto il tempo richiesto per farlo, l’unica altra alternativa sarà quella di aggiungere risorse al nostro team di sviluppo, ma saranno risorse alle quali non avremo il tempo di fare formazione e che quindi opereranno sulla codebase senza una corretta conoscenza. Per forza di cose anche loro andranno a produrre codice cattivo e questo non farà altro che incrementare il caos. Un bel giorno si arriverà al punto in cui semplicemente la codebase non sarà più manutenibile e sarà necessario ricominciare la scrittura del progetto pressoché da zero. Ora però vi starete chiedendo, sì ma come è fatto un codice di qualità e come si fa a scriverlo? Beh sappiate che se farete questa domanda a 100 programmatori diversi è molto probabile che otteniate 100 risposte diverse. Ci sarà chi vi dirà che un buon codice è scritto in modo semplice e diretto o in modo elegante o che un buon codice è un codice efficiente. Per come la vedo io quello che più si avvicina all’idea di un codice di qualità è la definizione data da Robert Martin nel libro Clean Code di cui vi lascio un link in descrizione. Piccola parentesi, vi lascio entrambi i link sia della versione inglese che è quella che ho letto io sia di quella italiana perché in giro ho letto che è particolarmente fedele e quindi se la preferite penso che possa andar bene comunque. In questo libro dicevamo Martin ci dice in pratica che un codice di qualità è un codice che può essere riletto e compreso in modo semplice sia dall’autore anche a distanza di tempo sia da altri programmatori che non l’abbiano mai visto prima. Se scriveremo il nostro codice puntando a questo obiettivo otterremo qualcosa che sarà più facile da estendere o da modificare sia per noi sia per quelli che verranno dopo di noi. E se ora vi state chiedendo sì ok ma come si fa a scrivere codice di qualità? Tenete presente che scrivere codice di qualità non è affatto semplice. Si tratta di un’attività che richiede un costante impegno perché proprio per i motivi espressi in precedenza saremo naturalmente portati a cercare scorciatoie che ci permettano di risparmiare tempo nell’immediato senza curarci del risultato finale e della sua riutilizzabilità nel futuro. Il primo passo da fare è capire che se percepiamo di non avere tempo a sofficienza per sviluppare un buon codice è probabile che la colpa sia nostra e con nostra intendo di noi sviluppatori. Questo perché in generale i nostri manager o i nostri clienti chiedono a noi quanto tempo è necessario per realizzare un software o un’ implementazione e se il nostro primo impulso è quello di rispondere con tempistiche molto strette per raccontentarli o per far vedere che siamo veloci e capaci nel nostro lavoro allora cadiamo nell’errore descritto prima e in realtà li stiamo semplicemente prendendo in giro e li stiamo spingendo ad imboccare la strada del fallimento. Quindi stabilito che sviluppare un buon codice non è un’operazione banale e richiede impegno e attenzione teniamo a mente che esistono tutta una serie di strategie e regole che possono essere applicate al netto del linguaggio di programmazione utilizzato e che permettono di mantenere un certo rigore e ordine all’interno del codice. Queste regole vanno dalla scelta dei nomi degli oggetti alla strutturazione delle funzioni passando per la gestione degli errori i commenti e persino la formatazione e la densità dei testi. Di sicuro approfondiremo vari di questi aspetti nei prossimi episodi del podcast tuttavia per ora cerchiamo di concentrarci sui due concetti di base che ci suggerisce Martin. Il primo è quello di considerare noi stessi come degli autori di romanzi saggi o articoli. Quando si scrive un testo infatti si vuole trasmettere un messaggio e per farlo è giusto che l’autore compia uno sforzo per scrivere qualcosa che i suoi lettori possano fruire e comprendere senza doversi impegnare a decifrare il testo stesso. L’idea è che la parte importante del testo sia il messaggio e il senso che vuole trasmettere e allo stesso modo nel codice la parte importante è il funzionamento e la logica che esso implementa. Tenendo a mente questa regola mentre scriviamo il nostro codice oggi un domani esso risulterà più facile da rileggere sia per noi sia per gli altri e ci si potrà quindi concentrare sul modificarlo ed estenderlo e non sul doverlo decifrare. Il secondo concetto fondamentale invece è quello che Martin definisce la regola dei boy scout. In generale i boy scout hanno questa abitudine quando si recano in mezzo alla natura si impegnano a lasciare i posti che visitano in condizioni migliori di quelle in cui li hanno trovati. Allo stesso modo quando un programmatore si trova a dover modificare un codice non troppo chiaro dovrebbe sforzarsi di migliorarne la leggibilità e la chiarezza per fare in modo che il prossimo lettore di quel codice, che non è detto che sarà qualcun altro ma potrebbe essere lui stesso a doverci ritornare, incontri meno difficoltà di quante ne incontrate lui la prima volta. Anche per oggi siamo giunti al termine di questo episodio. Io spero che l’argomento sia stato interessante. Vi ringrazio per aver ascoltato fin qui e vi ricordo che pensieri in codice è un dibattito e non un monologo quindi mi aspetto i vostri commenti e le vostre opinioni. Nel frattempo vi saluto e vi do appuntamento alla prossima settimana. Ciao!

Nascondi