Ad una parte di codice che funziona, ma scritta male, io ne preferisco una che non funziona, ma scritta bene.<\/p><\/blockquote>\n
(anche se a prima vista pu\u00f2 sembrare controintutivo, perch\u00e9 il nostro scopo alla fine \u00e8 scrivere applicazioni che funzionino).<\/p>\n
Il motivo di questa affermazione risulta comprensibile se si tiene conto anche del fattore tempo. Perch\u00e9 nel corso del tempo, quando bisogner\u00e0 cambiare quella riga di codice (e dico quando<\/em>, non se<\/em>) allora ci saranno altissime probabilit\u00e0 che la parte scritta male smetta di funzionare, mentre quella scritta bene potr\u00e0 essere analizzata e debuggata con successo e inizier\u00e0 velocemente a funzionare correttamente.<\/p>\n Inoltre il tempo per apportare le modifiche ad un pezzo di codice scritto male \u00e8 infinitamente pi\u00f9 lungo rispetto alla stessa modifica fatta su un progetto scritto secondo delle regole che vedremo pi\u00f9 avanti.<\/p>\n Ecco quindi che, se si tiene conto del fatto che il codice \u00e8 scritto una volta e modificato n<\/em> volte, \u00e8 chiaramente pi\u00f9 efficiente nel tempo avere una porzione di codice che funzioni n-1<\/em> 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.<\/p>\n Chi mi conosce sul forum<\/a> sa che questo \u00e8 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 \ud83d\ude42<\/p>\n Quando si parla di clean coding<\/strong> si intendono tutta una serie di pratiche e di accorgimenti, non necessariamente legati ad uno specifico linguaggio, il cui obiettivo \u00e8 rendere il codice sorgente pi\u00f9 chiaro da comprendere e con una struttura che renda pi\u00f9 agevole apportare modifiche successive.<\/p>\n Possiamo quindi dire che l’obiettivo ultimo del clean coding non \u00e8 quello di avere programmi pi\u00f9 veloci o file sorgenti pi\u00f9 piccoli o altri tipi di ottimizzazione, ma \u00e8 esclusivamente quello di ottenere codice sorgete in definitiva pi\u00f9 manutenibile.<\/p>\n Come cercher\u00f2 di spiegare pi\u00f9 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\u00f2 essere applicato anche al progetto pi\u00f9 piccolo e insignificante.<\/p>\n \u00c8 chiaro che se il progetto, invece, riveste anche una minima importanza economica e strategica, dal condizionale si passa all’imperativo ed \u00e8 necessario occuparsi del clean coding fin da subito, per non ostacolare la buona riuscita del progetto.<\/p>\n Questa obiezione \u00e8 spesso mossa da chi crede che tener conto del clean coding rubi del tempo alla fase di scrittura del codice, e questo \u00e8 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 \u00e8 richiesto alcuno sforzo aggiuntivo.<\/p>\n Non curarsi del clean coding per risparmiare tempo \u00e8 come scrivere “xk\u00e8” al posto di “perch\u00e9” per risparmiare fatica.<\/p>\n La convinzione, poi, che sia possibile in qualche modo tornare sui propri passi ed effettuare una fase di ripulita \u00e8 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\u00e0 difficile e error-prone<\/em> per cui di fronte ad un’applicazione funzionante, nessuno vuol modificare il codice sorgente correndo il rischio di introdurre un bug.<\/p>\n 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\u00ec via aspettando che poi, un giorno, ci sia una fase di ristrutturazione completa. Come invece ci insegnano i boyscout \u00e8 necessario che ogni singolo intervento lasci il bosco (o nel nostro caso il sorgente) pi\u00f9 pulito di come l’abbiamo trovato. Soltanto in questo modo si pu\u00f2 garantire nel tempo lo stato di salute del progetto.<\/p>\n Non esiste un elenco completo di regole da seguire affinch\u00e9 il codice possa essere considerato clean<\/em> o non-clean<\/em>. Con un approccio un po’ Zen potremmo dire che un codice \u00e8 clean quando guardandolo, capisci che \u00e8 clean \ud83d\ude42<\/p>\n Scherzi a parte, l’intero processo di sviluppo dell’applicazione pu\u00f2 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. Un progetto clean quindi passa per:<\/p>\n In alcuni casi la scelta effettuata per ciascuno di questi punti pu\u00f2 non essere di cruciale importanza, ma \u00e8 la scelta in s\u00e9, insieme alla consapevolezza dell’esistenza di questi punti a creare un processo<\/em> di sviluppo software.<\/p>\n Certo, dei primi quattro punti dar\u00f2 qualche accenno, per l’ultimo punto cercher\u00f2 di spendere qualche parola in pi\u00f9.<\/p>\n L’approccio classico allo sviluppo di un software passa dalle fasi di:<\/p>\n Questo \u00e8 banalmente il modello denominato waterfall<\/strong> ed \u00e8 in genere l’approccio usato anche dal vostro idraulico quando vi sostituisce la caldaia.<\/p>\n 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\u2026). L’accusa pi\u00f9 grossa rivolta verso l’approccio waterfall \u00e8 la difficolt\u00e0 nel gestire un cambiamento di requirement in corso di progetto, perch\u00e9 per sua natura una modifica richiesta durante la fase di realizzazione pu\u00f2 richiedere un notevole rework di analisi, progetto e realizzazione.<\/p>\n Su un progetto la cui durata prevista \u00e8 un anno \u00e8 impensabile non ricevere richieste di modifiche in corso d’opera quindi il modello waterfall non gode di molta popolarit\u00e0.<\/p>\n Un’altra accusa \u00e8 quella di causare l’analysis paralysis<\/em>, cio\u00e8 una fase di stallo durante la fase di analisi causata dalla necessit\u00e0 di dettagliare il comportamento del software fin nel pi\u00f9 piccolo dettaglio, visto che non sono previste nel modello altre fasi di analisi.<\/p>\n Non mi soffermer\u00f2 molto su questo aspetto, direi soltanto che \u00e8 impensabile gestire un progetto le cui risorse (sorgenti, documentazione, risorse) non sono organizzate secondo una rigida e condivisa gerarchia. 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? \ud83d\ude42 ) \u00e8 importante stabilire come vengono gestiti tag, branch e version number.<\/p>\n 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<\/a>) come sempre, non \u00e8 importante quale scegliete, ma il fatto di aver preso una scelta!<\/p>\n 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\u00e0 dell’applicazione permette in ultima analisi di poter effettuare il refactoring del codice con la sicurezza di non introdurre nessun bug di regressione.<\/p>\n L’utilizzo di unit test offre anche un innumerevole numero di altri vantaggi (qui http:\/\/goo.gl\/hQBmFZ<\/a> un assaggio) ma quello che vorrei sottolineare \u00e8 che anche per i test esistono diversi approcci<\/em> come il classico TDD o il pi\u00f9 moderno BDD. Anche in questo caso, fate la vostra scelta magari dando un’occhiata a questo articolo (http:\/\/goo.gl\/MycWDl<\/a> e questa interessante lista http:\/\/goo.gl\/qAfE0<\/a>).<\/p>\n Autore dei due principali volumi sull’argomento (link pi\u00f9 avanti nell’articolo) e di una serie di video che potremmo quantomeno definire bizzarri<\/em>, lo zio Bob ha fatto come sua personale crociata (e business…) proprio il clean code\u2026 che prende questo il nome proprio dai suoi libri.<\/p>\n \u00c8 impossibile riassumere in poche righe i consigli e i suggerimenti raccolti nei suoi libri, vi avviso per\u00f2 che guarderete al vostro codice veramente con occhi nuovi.<\/p>\n Quanto deve essere lungo un metodo? 6 righe al massimo. E una classe? 30. Hai un “if” all’interno di un metodo? \u00e8 indice di un cattivo modello. Hai uno “switch” ? hai sbagliato mestiere.<\/p>\n L’acronimo SOLID<\/strong> in programmazione fa prorio riferimento a 5 principi fondamentali raccolti da Martin alla base della buona scrittura di un codice sorgente:<\/p>\n![\"clean-coding-ios-mobile\"](\"http:\/\/www.devapp.it\/wordpress\/wp-content\/uploads\/2014\/02\/clean-coding-ios-mobile.jpg\")
<\/a><\/p>\nCosa si intende per clean coding?<\/h1>\n
Chi dovrebbe curarsi del clean coding?<\/h1>\n
Ho fretta e devo consegnare il progetto, non posso pensarci dopo?<\/h1>\n
In dettaglio di che tecniche stai parlando?<\/h1>\n
\nPer 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.<\/p>\n\n
Puoi descrivere pi\u00f9 in dettaglio questi punti?<\/h1>\n
Metodologia di sviluppo<\/h2>\n
\n
\nNel corso degli anni (a partire dagli anni ’80) qualcuno si \u00e8 chiesta se questo approccio un po’ “ingenuo” fosse l’approccio pi\u00f9 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<\/strong>.<\/p>\nUna struttura ordinata per le risorse del progetto<\/h2>\n
\nConsiglio di dare un’occhiata alle slide di Massimo Oliviero ( http:\/\/goo.gl\/H7e1nh<\/a> ) sull’organizzazione delle risorse all’interno di un progetto Xcode con il quale concordo al 100% (trovate anche un mio articolo<\/a> qui su devAPP che pu\u00f2 tornarvi utile).<\/p>\nOrganizzazione delle versioni e branch<\/h2>\n
Unit test e integration test<\/h2>\n
Design e struttura del codice sorgente<\/h2>\n
Non si pu\u00f2 parlare di clean coding e codice sorgente senza citare il pi\u00f9 grande (e divertente) divulgatore e autore di testi sull’argomento, lo zio Bob Martin<\/strong>.<\/p>\n