Inizierò questo articolo con un’affermazione che mi farà apparire un po’ matto:

Ad una parte di codice che funziona, ma scritta male, io ne preferisco una che non funziona, ma scritta bene.

(anche se a prima vista può sembrare controintutivo, perché il nostro scopo alla fine è scrivere applicazioni che funzionino).

Il motivo di questa affermazione risulta comprensibile se si tiene conto anche del fattore tempo. Perché nel corso del tempo, quando bisognerà cambiare quella riga di codice (e dico quando, non se) allora ci saranno altissime probabilità che la parte scritta male smetta di funzionare, mentre quella scritta bene potrà essere analizzata e debuggata con successo e inizierà velocemente a funzionare correttamente.

Inoltre il tempo per apportare le modifiche ad un pezzo di codice scritto male è infinitamente più lungo rispetto alla stessa modifica fatta su un progetto scritto secondo delle regole che vedremo più avanti.

Ecco quindi che, se si tiene conto del fatto che il codice è scritto una volta e modificato n volte, è chiaramente più efficiente nel tempo avere una porzione di codice che funzioni n-1 volte (e che richieda brevi tempi d’intervento) piuttosto che una porzione che vada bene soltanto la prima volta e che poi richieda lacrime e sangue per ciascuna successiva modifica.

Chi mi conosce sul forum sa che questo è un po’ il mio pallino da sempre e che preferisco rispondere a una domanda sullo stile piuttosto che fornire una riga di codice che risolva il problema e in quest’articolo vorrei affrontare proprio questo problema, fornendo delle risorse utili a chi volesse approfondire l’argomento e soprattutto per dimostrare che non sono l’unico pazzo a questo mondo 🙂

Cosa si intende per clean coding?

Quando si parla di clean coding si intendono tutta una serie di pratiche e di accorgimenti, non necessariamente legati ad uno specifico linguaggio, il cui obiettivo è rendere il codice sorgente più chiaro da comprendere e con una struttura che renda più agevole apportare modifiche successive.

Possiamo quindi dire che l’obiettivo ultimo del clean coding non è quello di avere programmi più veloci o file sorgenti più piccoli o altri tipi di ottimizzazione, ma è esclusivamente quello di ottenere codice sorgete in definitiva più manutenibile.

Chi dovrebbe curarsi del clean coding?

Come cercherò di spiegare più avanti, curarsi del clean coding non aggiunge overhead alla stesura di un codice sorgente, quindi in un certo senso possiamo dire che non ha controindicazioni e che quindi può essere applicato anche al progetto più piccolo e insignificante.

È chiaro che se il progetto, invece, riveste anche una minima importanza economica e strategica, dal condizionale si passa all’imperativo ed è necessario occuparsi del clean coding fin da subito, per non ostacolare la buona riuscita del progetto.

Ho fretta e devo consegnare il progetto, non posso pensarci dopo?

Questa obiezione è spesso mossa da chi crede che tener conto del clean coding rubi del tempo alla fase di scrittura del codice, e questo è totalmente falso. Come abbiamo detto all’interno del clean coding rientrano una moltitudine di pratiche e di best practice e, anche se alcune di esse possono richiedere un investimento in termini di tempo, la maggior parte delle tecniche richiedono esclusivamente un modo diverso di scrivere il nostro codice sorgente, e quindi non è richiesto alcuno sforzo aggiuntivo.

Non curarsi del clean coding per risparmiare tempo è come scrivere “xkè” al posto di “perché” per risparmiare fatica.

La convinzione, poi, che sia possibile in qualche modo tornare sui propri passi ed effettuare una fase di ripulita è anch’essa errata per la ragione fondamentale che, visto che le regole del clean coding non sono state seguite, allora effettuare le modifiche al codice sarà difficile e error-prone per cui di fronte ad un’applicazione funzionante, nessuno vuol modificare il codice sorgente correndo il rischio di introdurre un bug.

Il codice in questo contesto viene paragonato ad un palazzo abbandonato dove un giorno viene spaccato un vetro, il giorno dopo rubata una porta e così via aspettando che poi, un giorno, ci sia una fase di ristrutturazione completa. Come invece ci insegnano i boyscout è necessario che ogni singolo intervento lasci il bosco (o nel nostro caso il sorgente) più pulito di come l’abbiamo trovato. Soltanto in questo modo si può garantire nel tempo lo stato di salute del progetto.

In dettaglio di che tecniche stai parlando?

Non esiste un elenco completo di regole da seguire affinché il codice possa essere considerato clean o non-clean. Con un approccio un po’ Zen potremmo dire che un codice è clean quando guardandolo, capisci che è clean 🙂

Scherzi a parte, l’intero processo di sviluppo dell’applicazione può e dovrebbe essere indirizzato all’ottenimento di un sorgente chiaro e utilizzabile, in tutte le sue fasi, dalla fase di stima alla fase di manutenzione.
Per questa ragione quando si parla di clean coding si tende a considerare anche la metodologia di sviluppo, la struttura del progetto, il versioning, i test case fino alla fase di manutenzione e archiviazione, passando ovviamente dalla struttura degli oggetti e delle classi.

Un progetto clean quindi passa per:

• Una chiara metodologia di sviluppo
• Una struttura ordinata delle risorse che costituiscono il progetto.
• Un’organizzazione delle versioni e dei branch di sviluppo.
• Un nutrito set di test case e integration test per agevolare il refactoring.
• Una struttura del codice chiara e che permette agevolmente le modifiche.

In alcuni casi la scelta effettuata per ciascuno di questi punti può non essere di cruciale importanza, ma è la scelta in sé, insieme alla consapevolezza dell’esistenza di questi punti a creare un processo di sviluppo software.

Puoi descrivere più in dettaglio questi punti?

Certo, dei primi quattro punti darò qualche accenno, per l’ultimo punto cercherò di spendere qualche parola in più.

Metodologia di sviluppo

L’approccio classico allo sviluppo di un software passa dalle fasi di:

1. Analisi
2. Progetto
3. Realizzazione
4. Collaudo
5. Manutenzione.

Questo è banalmente il modello denominato waterfall ed è in genere l’approccio usato anche dal vostro idraulico quando vi sostituisce la caldaia.

Esamina il guasto (analisi) fa un progetto (“bisogna cambiare la caldaia”), la realizza (cambia la caldaia), la collauda (si accende? Ok) e ne pianifica la manutenzione (ci vediamo il prossimo anno…).
Nel corso degli anni (a partire dagli anni ’80) qualcuno si è chiesta se questo approccio un po’ “ingenuo” fosse l’approccio più performante anche per lo sviluppo di applicazioni, e nuove metodologie sono apparse come funghi, la maggior parte delle quali rientranti all’interno delle famiglia delle cosiddette metodologie agili.

L’accusa più grossa rivolta verso l’approccio waterfall è la difficoltà nel gestire un cambiamento di requirement in corso di progetto, perché per sua natura una modifica richiesta durante la fase di realizzazione può richiedere un notevole rework di analisi, progetto e realizzazione.

Su un progetto la cui durata prevista è un anno è impensabile non ricevere richieste di modifiche in corso d’opera quindi il modello waterfall non gode di molta popolarità.

Un’altra accusa è quella di causare l’analysis paralysis, cioè una fase di stallo durante la fase di analisi causata dalla necessità di dettagliare il comportamento del software fin nel più piccolo dettaglio, visto che non sono previste nel modello altre fasi di analisi.

Una struttura ordinata per le risorse del progetto

Non mi soffermerò molto su questo aspetto, direi soltanto che è impensabile gestire un progetto le cui risorse (sorgenti, documentazione, risorse) non sono organizzate secondo una rigida e condivisa gerarchia.
Consiglio di dare un’occhiata alle slide di Massimo Oliviero ( http://goo.gl/H7e1nh ) sull’organizzazione delle risorse all’interno di un progetto Xcode con il quale concordo al 100% (trovate anche un mio articolo qui su devAPP che può tornarvi utile).

Organizzazione delle versioni e branch

Credo che sia ormai scontata l’esigenza di utilizzare un sistema di controllo versione (CVS) in qualsiasi progetto di qualsiasi dimensione, ma viene invece spesso sottovalutata la logica con cui il sofware deve essere utilizzato. Quale che sia quindi il tool che si sia deciso di utilizzare (git, svn, mercurial) (svn? really? 🙂 ) è importante stabilire come vengono gestiti tag, branch e version number.

Per GIT sono stati studiati diversi workflow come, gitflow, featured branch, etc. se volete scegliere quello che fa per voi date una lettura a questo articolo (http://goo.gl/hV6Zan) come sempre, non è importante quale scegliete, ma il fatto di aver preso una scelta!

Unit test e integration test

I test hanno lo scopo di assicurare che il software abbia determinati requisiti. L’utilizzo di un elevato numero di test che copra tutte le funzionalità dell’applicazione permette in ultima analisi di poter effettuare il refactoring del codice con la sicurezza di non introdurre nessun bug di regressione.

L’utilizzo di unit test offre anche un innumerevole numero di altri vantaggi (qui http://goo.gl/hQBmFZ un assaggio) ma quello che vorrei sottolineare è che anche per i test esistono diversi approcci come il classico TDD o il più moderno BDD. Anche in questo caso, fate la vostra scelta magari dando un’occhiata a questo articolo (http://goo.gl/MycWDl e questa interessante lista http://goo.gl/qAfE0).

Design e struttura del codice sorgente

Non si può parlare di clean coding e codice sorgente senza citare il più grande (e divertente) divulgatore e autore di testi sull’argomento, lo zio Bob Martin.

Autore dei due principali volumi sull’argomento (link più avanti nell’articolo) e di una serie di video che potremmo quantomeno definire bizzarri, lo zio Bob ha fatto come sua personale crociata (e business…) proprio il clean code… che prende questo il nome proprio dai suoi libri.

È impossibile riassumere in poche righe i consigli e i suggerimenti raccolti nei suoi libri, vi avviso però che guarderete al vostro codice veramente con occhi nuovi.

Quanto deve essere lungo un metodo? 6 righe al massimo. E una classe? 30. Hai un “if” all’interno di un metodo? è indice di un cattivo modello. Hai uno “switch” ? hai sbagliato mestiere.

L’acronimo SOLID in programmazione fa prorio riferimento a 5 principi fondamentali raccolti da Martin alla base della buona scrittura di un codice sorgente:

Ciascuno di essi meriterebbe un articolo a sé, il consiglio è quello di leggere almeno uno dei due suoi libri, presente in dodicesima posizione tra i libri di programmazione più influenti della storia (vedi: http://goo.gl/REx2 preceduto da libri come GEB, K&R e GoF… mica Topolino).

Un altro autore che ha dedicato del tempo a spiegare a noi mortali come un codice sorgente deve essere scritto è Martin Fowler che nel 1999 ha scritto un libro poi divenuto la Bibbia del Code Refactoring (http://goo.gl/2j7tgy) che contiene uno tra i più apprezzati elenchi di code smell, ovvero segni evidenti nel codice sorgente di un cattivo design e struttura delle codice o più in generale di scarsa attenzione alla qualità del codice prodotto.
Per fare un esempio “Primitive Obsession” e un tipo di code smell presente quando il programmatore tende ad usare i tipi primitivi (dizionary, array, stringhe) per rappresentare oggetti che sarebbe più indicato rappresentare con classi.

È importante notare che benché code smell e SOLID Principles siano tecnicamente molto diversi tra loro, sono in un certo senso correlati: i primi sono dei “difetti” che possiamo notare nel codice sorgente, i secondi sono dei “principi” da seguire per evitare di incapparvi. Ad esempio il code smell “shotgun surgery” che si ha quando a causa di una piccola modifica è necessario modificare una lunga lista di classi, è strettamente legato al principio SRP (Single Reponsability Principle) cioè se tentiamo di programmare rispettando il SRP non ci troveremo mai con il problema dello “shotgun surgery”.

Ok mi hai convinto, dammi qualche link su cui trovare materiale aggiuntivo”

Per le metodologie di sviluppo il punto di riferimento iniziale è sicuramente wikipedia: (http://it.wikipedia.org/wiki/Metodologia_di_sviluppo_del_software) e poi sicuramente il gruppo che sta dietro l’agile day (http://www.agileday.it/front/) il prossimo è fissato per novembre 2014, save the date!
Se volete leggere un testo sullo sviluppo Agile posso suggerire questo qui: http://goo.gl/i0J8Yf non sono un espertissimo in materia e questo libro mi ha chiarito un po’ le idee.

Per l’utilizzo di GIT trovate un esempio dei diversi workflow qui: http://goo.gl/hV6Zan, mentre se proprio siete a digiuno di GIT ecco un paio di link:

• Git Pro: Il libro di Scott Chacon completametne gratuito e liberamente consultabile.http://git-scm.com/book/it
• Try git: Un breve corso interattivo per imparare i rudimenti di Git. Il tutto alla maniera dei ragazzi di Envylabs e CodeShool. http://try.github.io/levels/1/challenges/1
• Learn git branching: Un videogioco, no un tutorial, no un videogioco… insomma imparare Git in modo interattivo. http://pcottle.github.io/learnGitBranching/
• Github Help: A chi chiedi aiuto su git se non al dio di git Github? https://help.github.com/

Per unit test su iOS non c’è moltissimo, l’unico libro è uscito già un po’ di tempo fa e quindi non è aggiornato con i nuovi XCTest però a parte questa differenza sintattica il succo del libro resta sempre validissimo.

Segnalo poi il blog di Jhon Reid (http://qualitycoding.org/) autore tra l’altro di due framework molto diffusi per l’obj mock e testing.

Segnatevi anche il feed di questo blog (http://iosunittesting.com/) uno dei pochi che scrive esclusivamente di TDD e iOS.

Per l’approccio BDD il framework più diffuso è Kiwi (https://github.com/allending/Kiwi‎) e se la guida non fosse sufficiente vi consiglio un piccolo ebook disponibile su iBook store, io l’ho comprato qualche anno fa ed è stato molto interessante da seguire.

Per tutto quello che riguarda la stesura del codice sorgente non posso non partire dalla bibbia del design pattern (http://goo.gl/y28PaX) o la sua versione aggiornata specifica per iOS (http://goo.gl/2fCLVK) o Cocoa (http://goo.gl/yHqWB4)
Il sito di Bob Martin è http://cleancoders.com/, mentre i due libri più famosi sono “Clean Code” (http://goo.gl/uZ7N9o) e “The Clean Coders” (http://goo.gl/EwvapW)

Sul code smell potete leggere l’articolo di Jeff Atwood (coding horror http://goo.gl/JASkO) o direttamente il libro di Martin Fowler (http://goo.gl/2j7tgy). Se cercate invece un riassunto da stampare e tenere sempre a portata di mano ecco un bel PDF: http://goo.gl/cwSWxQ.

Personalmente ho apprezzato anche una serie di video realizzati da uno sviluppatore rumeno Patkos Csaba (http://goo.gl/4YyRCg video a pagamento) dove i code smell sono spiegati utilizzando codice PHP, ma sono comunque validi per qualsiasi linguaggio e non è richiesta una competenza specifica di php.

Se volete analizzare il vostro codice iOS per valutarne lo stato di salute, potete utilizzare due strumenti: il primo è AppCode un ide alternativo ad XCode (http://www.jetbrains.com/objc/ programma a pagamento) che tra le mille funzionalità ha anche quella di “inspect code” evidenziando problemi come codice non utilizzato, codice non raggiungibile, stringhe non localizzate etc.

L’altra alternativa è free e richiede però un po’ di dimestichezza nell’utilizzo: OC-Lint (http://oclint.org/) in grado di analizzare il codice sorgente, confrontarlo con delle regole standard oppure definite da voi (massima lunghezza di una riga 120 caratteri) e generare un report in formato HTML.

Spero di aver dimostrato con questo articolo che, superato quel momento in cui si riesce a scrivere del codice che funziona, c’è tutto un intero mondo di roba da studiare per affinare il proprio stile. Un po’ come i bambini che prima imparano a scrivere, poi cercano di scrivere bene, se l’importante fosse solo comunicare i libri sui nostri scaffali sarebbero pieni di xké, LOL e cmq.

A questo punto non mi resta che augurarvi buona programmazione (clean mi raccomando!)