{"id":803,"date":"2018-04-19T12:44:11","date_gmt":"2018-04-19T10:44:11","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/scrivere-codice-chiaro\/"},"modified":"2018-04-19T12:44:11","modified_gmt":"2018-04-19T10:44:11","slug":"scrivere-codice-chiaro","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/scrivere-codice-chiaro\/","title":{"rendered":"Scrivere codice chiaro"},"content":{"rendered":"

Il codice che funziona non \u00e8 necessariamente un buon codice. Il codice deve anche essere facile da leggere, capire e modificare. Ha bisogno di chiarezza e per riuscirci deve essere organizzato bene, con un’attenta pianificazione e un’adeguata separazione di idee che precedono l’apertura dell’editor. Scrivere codice perch\u00e9 sia chiaro \u00e8 qualcosa che separa i grandi sviluppatori da quelli solamente bravi e ci sono alcuni principi di base che possono metterci su un tale percorso.<\/p>\n

Nota: sebbene i principi in questo articolo siano applicabili a una variet\u00e0 di linguaggi di programmazione, la maggior parte degli esempi deriva da JavaScript orientato agli oggetti. Se non ne avete familiarit\u00e0, <\/em>A List Apart ha degli articoli sul module pattern<\/a> e su prototypal inheritance<\/a> per aiutarvi a recuperare.<\/em><\/p>\n

\n

Il principio di singola responsabilit\u00e0<\/h2>\n

Immaginate di lavorare a un progetto in casa e di prendere un trapano per infilare una vite nel muro. Quando staccate il trapano dalla vite, scoprite che questo trapano ha una caratteristica interessante: schizza un composto di cartongesso ad asciugatura rapida sopra alla vite infilata per nasconderla. Beh, \u00e8 ottimo se volete dipingere sopra la vite, ma non \u00e8 sempre questo il caso. Non dovreste avere un secondo trapano solo per fare un buco in qualcosa. Il trapano sarebbe molto pi\u00f9 usabile e affidabile se facesse solo una cosa e sarebbe anche abbastanza flessibile da poter essere usato in una serie di situazioni.<\/p>\n

Il principio di singola responsabilit\u00e0 stabilisce che un blocco di codice dovrebbe fare una cosa sola e farla bene. Come il trapano di cui sopra, limitarne la funzionalit\u00e0 in realt\u00e0 fa aumentare l’utilit\u00e0 di un blocco di codice. Programmare in questo modo non solo ci evita dei mal di testa, ma li eviter\u00e0 anche ai futuri sviluppatori di questo progetto.<\/p>\n

Pensate alle funzioni e ai metodi in termini di responsabilit\u00e0. Man mano che aumentano le sue responsabilit\u00e0, un blocco di codice diventa meno flessibile e affidabile, pi\u00f9 dipendente dai cambiamenti e pi\u00f9 suscettibile agli errori. Per maggior chiarezza, ogni funzione o metodo dovrebbe avere una responsabilit\u00e0.<\/p>\n

Se state descrivendo quello che fa una funzione e dovete usare la parola \u201ce\u201d, quella funzione probabilmente \u00e8 troppo complessa. Quello che fa una funzione dovrebbe essere sufficientemente semplice da spiegare solo con un nome di funzione descrittivo e degli argomenti descrittivi.<\/p>\n

Recentemente, mi \u00e8 stato affidato il compito di creare una versione elettronica del test di personalit\u00e0 Myers-Briggs. L’avevo gi\u00e0 fatto in passato e, quando mi ero avvicinato al problema alcuni anni fa, avevo programmato una funzione gigantesca chiamata processForm<\/code>: raccoglieva i punteggi, generava i grafici e si occupava di tutto nel DOM per mostrare le cose all’utente.<\/p>\n

Il problema era che se si doveva cambiare qualcosa, si doveva cercare in una valanga di codice per capire dove fare le modifiche. Inoltre, se qualcosa andava male nel mezzo della funzione, era molto pi\u00f9 difficile trovare l’errore.<\/p>\n

Quindi, quando mi sono trovato di fronte al problema questa volta, ho invece suddiviso tutto in funzioni a singola responsabilit\u00e0 impacchettate in un oggetto module. La funzione risultante chiamata a fronte dell’invio della form era cos\u00ec:<\/p>\n

return<\/span> {<\/span>\n    processForm:<\/span> function<\/span>(<\/span>)<\/span> {<\/span>\n        getScores(<\/span>)<\/span>;<\/span>\n        calculatePercentages(<\/span>)<\/span>;<\/span>\n        createCharts(<\/span>)<\/span>;<\/span>\n        showResults(<\/span>)<\/span>;<\/span>\n    }<\/span>\n}<\/span>;<\/span><\/code><\/pre>\n
Estremamente facile da leggere, comprendere e modificare: anche un non-programmatore pu\u00f2 capirne il senso. E ognuna di quelle funzioni fa (avete indovinato!) una sola cosa. Questo \u00e8 il principio di singola responsabilit\u00e0 in azione.<\/p>\n
Se volessi aggiungere la validazione della form, piuttosto che dover modificare una gigantesca function funzionante (potenzialmente introducendovi degli errori), potrei semplicemente aggiungere un nuovo metodo. Questo approccio permette anche alla logica e alle variabili correlate di essere suddivise, riducendo i conflitti a fronte di una maggior affidabilit\u00e0 e rendendo molto semplice riutilizzare la funzione per altri scopi, se necessario.<\/p>\n
Quindi, ricordate: una funzione, una responsabilit\u00e0. Le grandi funzioni sono dove le classi vanno a nascondersi. Se una funzione fa molte cose strettamente collegate e che lavorano con gli stessi dati, avrebbe pi\u00f9 senso spezzarla in un oggetto con dei metodi, in maniera simile a quello che ho fatto con la mia grande funzione per la form.<\/p>\n<\/div>\n
\n
Command-query separation<\/h2>\n
La catena di email pi\u00f9 divertente che abbia mai visto \u00e8 stata la serie di poster di Missing Missy di David Thorne<\/a> riguardante un gatto scomparso. Ogni volta che la sua collega Shannon faceva una richiesta, David obbediva, ma ci metteva del suo e inviava qualcosa di diverso da ci\u00f2 che ci si aspettava. Lo scambio \u00e8 davvero divertente e vale la pena leggerlo, ma \u00e8 meno divertente quando il vostro codice fa la stessa cosa.<\/p>\n
La command-query separation fornisce una base per salvaguardare il vostro codice di fronte agli effetti collaterali involontari per evitare sorprese quando vengono fatte delle chiamate di funzioni. Le funzioni ricadono in una delle due seguenti categorie: comandi<\/em>, che fanno un’azione, e queries<\/em>, che rispondono a una domanda. Non dovreste mischiarle. Prendiamo in considerazione la seguente funzione:<\/p>\n
function<\/span> getFirstName(<\/span>)<\/span> {<\/span>\n    var<\/span> firstName =<\/span> document.<\/span>querySelector(<\/span>\"#firstName\"<\/span>)<\/span>.<\/span>value;<\/span>\n    firstName =<\/span> firstName.<\/span>toLowerCase(<\/span>)<\/span>;<\/span>\n    setCookie(<\/span>\"firstName\"<\/span>,<\/span> firstName)<\/span>;<\/span>\n    if<\/span> (<\/span>firstName ==<\/span>=<\/span> null<\/span>)<\/span> {<\/span>\n        return<\/span> \"\"<\/span>;<\/span>\n    }<\/span>\n    return<\/span> firstName;<\/span>\n}<\/span>\n \nvar<\/span> activeFirstName =<\/span> getFirstName(<\/span>)<\/span>;<\/span><\/code><\/pre>\n
Questo \u00e8 un esempio semplicistico: la maggior parte degli effetti collaterali sono difficili da trovare, ma potete vedere alcuni imprevisti effetti collaterali potenziali in azione.<\/p>\n
Il nome della funzione, getFirstName<\/code>, ci dice che la funzione ritorner\u00e0 il nome proprio. Ma la prima cosa che fa \u00e8 convertire il nome in lettere minuscole. Il nome dice che ottiene qualcosa (una query), ma sta anche cambiando lo stato dei dati (un comando): un effetto collaterale che non \u00e8 chiaro dal nome della funzione.<\/p>\n
Peggio ancora, la funzione poi imposta un cookie per il nome proprio senza dircelo, potenzialmente sovrascrivendo qualcosa su cui avremmo potuto fare affidamento. Una funzione query non dovrebbe mai, per nessun motivo, sovrascrivere dati.<\/p>\n
Una buona regola pratica \u00e8 che se la vostra funzione risponde a una domanda, dovrebbe ritornare un valore e non<\/em> alterare lo stato dei dati. Di contro, se la vostra funzione fa qualcosa, dovrebbe alterare lo stato dei dati e non<\/em> ritornare un valore. Per massima chiarezza, una funzione non dovrebbe mai ritornare un valore e<\/em> alterare lo stato dei dati.<\/p>\n
Una versione migliore del codice di cui sopra sarebbe:<\/p>\n
function<\/span> getFirstName(<\/span>)<\/span> {<\/span>\n    var<\/span> firstName =<\/span> document.<\/span>querySelector(<\/span>\"#firstName\"<\/span>)<\/span>.<\/span>value;<\/span>\n    if<\/span> (<\/span>firstName ==<\/span>=<\/span> null<\/span>)<\/span> {<\/span>\n        return<\/span> \"\"<\/span>;<\/span>\n    }<\/span>\n    return<\/span> firstName;<\/span>\n}<\/span>\n \nsetCookie(<\/span>\"firstName\"<\/span>,<\/span> getFirstName(<\/span>)<\/span>.<\/span>toLowerCase(<\/span>)<\/span>)<\/span>;<\/span><\/code><\/pre>\n
Questo \u00e8 un esempio base, ma spero che possiate vedere come questa separazione possa chiarire lo scopo e prevenire errori. Al crescere delle dimensioni delle funzioni e della code base, la separazione diventa molto pi\u00f9 importante, dal momento che cercare la definizione della funzione ogni volta che la si vuole usare solo per scoprire cosa fa non \u00e8 un modo efficiente di sfruttare il tempo di qualcuno.<\/p>\n<\/div>\n
\n
Loose coupling<\/h2>\n
Consideriamo la differenza che c’\u00e8 tra un puzzle e i mattoncini Lego. Con un puzzle, c’\u00e8 solo un modo per mettere insieme i pezzi e c’\u00e8 un unico prodotto finito. Con il Lego, potete mettere insieme i pezzi in qualsiasi maniera si voglia per ottenere qualunque risultato finale si desideri. Se doveste scegliere uno di questi tipi di giochi di costruzione con cui lavorare prima di sapere quello che creerete, quale scegliereste?<\/p>\n
Coupling<\/em> \u00e8 una misura di quanto un’unit\u00e0 di programma faccia affidamento sulle altre. Troppo coupling (o un coupling troppo stringente) \u00e8 rigido e andrebbe evitato: \u00e8 il puzzle. Vogliamo che il nostro codice sia flessibile, come i mattoncini Lego. Questo \u00e8 il loose coupling e generalmente risulta in maggiore chiarezza.<\/p>\n
Ricordate: il codice dovrebbe essere sufficientemente flessibile da coprire un’ampia variet\u00e0 di casi d’uso. Se vi trovate a copiare e incollare del codice facendo piccoli cambiamenti o a riscrivere codice perch\u00e9 il codice \u00e8 cambiato da qualche altra parte, state osservando il tight coupling in azione. (Per esempio, per rendere la precedente funzione getFirstName<\/code> riutilizzabile, potreste sostituire lo hard-coded firstName<\/code> con un generico ID passato alla funzione). Altri segni di ci\u00f2 includono gli ID hard-coded nelle funzioni, troppi parametri di funzione, molteplici funzioni simili e funzioni grandi che violano il principio di singola responsabilit\u00e0.<\/p>\n
Il tight coupling \u00e8 pi\u00f9 diffuso in un gruppo di funzioni e variabili che dovrebbero in realt\u00e0 essere una classe, ma pu\u00f2 anche succedere quando delle classi dipendono da metodi o propriet\u00e0 di altre classi. Se avete dei problemi con le interdipendenze nelle funzioni, \u00e8 probabilmente ora di pensare a suddividere le funzioni in una classe.<\/p>\n
Mi ci sono imbattuto mentre osservavo del codice per una serie di manopole interattive. Le manopole avevano un numero di variabili, incluse le dimensioni, la taglia della manopola, la dimensione del perno e cos\u00ec via. A causa di tutto ci\u00f2, lo sviluppatore era costretto o a usare una quantit\u00e0 assurda di parametri di funzione o a creare molteplici copie di ogni funzione con le variabili hard-coded in ciascuna di esse. Inoltre, ogni manopola faceva qualcosa di diverso quando ci si interagiva. Questo ha portato a tre insiemi di funzioni quasi identiche, una per ciascuna manopola. In breve, il coupling \u00e8 aumentato a causa dell’hard coding delle variabili e del comportamento, cos\u00ec, come in un puzzle, c’era solo un modo per mettere insieme quei pezzi. La codebase era inutilmente complessa.<\/p>\n
Abbiamo risolto il problema suddividendo le funzioni e le variabili in una classe riutilizzabile che veniva istanziata per ognuna delle tre manopole. Abbiamo impostato la classe perch\u00e9 prendesse una funzione come argomento per l’output, quindi diversi risultati potrebbero essere configurati quando i singoli oggetti manopola vengono istanziati. Come risultato, avevamo meno funzioni e le variabili sono state memorizzate solo in un posto, rendendo gli aggiornamenti molto pi\u00f9 semplici.<\/p>\n
Le classi che interagiscono le une con le altre possono inoltre essere la causa di tight coupling. Supponiamo di avere una classe che pu\u00f2 creare oggetti di un’altra classe, come un corso al college che possa creare degli studenti. La nostra classe CollegeCourse<\/code> funziona bene. Ma poi abbiamo bisogno di aggiungere un parametro al costruttore della classe Student<\/code>. Oh no! Adesso dobbiamo modificare la nostra classe CollegeCourse<\/code> per tenere conto del cambiamento nella classe Student<\/code>.<\/p>\n
var<\/span> CollegeCourse =<\/span> (<\/span>function<\/span>(<\/span>)<\/span> {<\/span>\n    function<\/span> createStudent_WRONG(<\/span>firstName,<\/span> lastName,<\/span> studentID)<\/span> {<\/span>\n        \/*\n        If the Student constructor changes, we'll have to modify this method and all calls to it, too!\n        *\/<\/span>\n    }<\/span>\n\n    function<\/span> createStudent_RIGHT(<\/span>optionsObject)<\/span> {<\/span>\n        \/*\n        Passing an object as an argument allows the Student object to deal with the change. We may need to change this method, but we won\u2019t need to change any existing calls to it.\n        *\/<\/span>\n    }<\/span>\n}<\/span>(<\/span>)<\/span>)<\/span>;<\/span><\/code><\/pre>\n
Non dovreste dover modificare una classe perch\u00e9 un’altra classe \u00e8 cambiata. Questo \u00e8 un classico caso di tight coupling. I parametri constructor possono essere passati come oggetto con l’oggetto ricevente che ha dei valori di fallback di default, che allenta il coupling e significa che il codice non smetter\u00e0 di funzionare a dovere quando aggiungerete dei nuovi parametri.<\/p>\n
Il punto \u00e8 che dovreste costruire il vostro codice come dei mattoncini Lego non come dei pezzi di un puzzle. Se vi trovate ad affrontare problemi simili a quelli di cui sopra, il problema \u00e8 probabilmente il tight coupling.<\/p>\n<\/div>\n
\n
High cohesion<\/h2>\n
Avete mai visto un bambino pulire una stanza mettendo tutto in un cassetto? Certo, funziona, ma \u00e8 impossibile trovare una qualsiasi cosa e vengono messe assieme anche cose che non hanno alcuna relazione tra esse. Lo stesso pu\u00f2 succedere con il nostro codice se non cerchiamo di ottenere un alto livello di coesione.<\/p>\n
La cohesion<\/em> \u00e8 una misura di quanto le varie unit\u00e0 del programma possano andare bene assieme. Un alto livello di coesione va bene e aggiunge chiarezza ai blocchi di codice; un basso livello di coesione non va bene e porta a molta confusione. Le funzioni e i metodi in un blocco di codice dovrebbero aver senso insieme: ossia, avranno un alto livello di coesione.<\/p>\n
High cohesion significa tenere insieme cose correlate, come le funzioni del database o le funzioni relative ad un particolare elemento, in un blocco unico o in un solo modulo. Questo aiuta non solo con la comprensione di come tali cose siano organizzate e dove trovarle, ma anche con la prevenzione di conflitti di naming. Se avete 30 funzioni, le probabilit\u00e0 di un conflitto di naming saranno molto pi\u00f9 alte rispetto a quando avete 30 metodi suddivisi in quattro classi.<\/p>\n
Se due o tre funzioni usano le stesse variabili, vanno messe insieme: si tratta di un ottimo caso per un oggetto. Se avete una serie di funzioni e variabili che controllano un elemento della pagina, come uno slider, \u00e8 una grande opportunit\u00e0 per una high cohesion, quindi dovreste unirli in un oggetto.<\/p>\n
Ricordate l’esempio che abbiamo fatto prima sulla classe che faceva decoupling della soluzione per la manopola? Si tratta di un ottimo esempio di high cohesion che cura il tight coupling. In quel caso, high cohesion e tight coupling erano ai lati opposti di una scala indicizzata e concentrarsi su una sistemava l’altra.<\/p>\n
Il codice ripetuto \u00e8 un segno sicuro di bassa coesione. Righe di codice simili dovrebbero essere scomposte in funzioni e funzioni simili dovrebbero essere scomposte in classi. La regola pratica qui \u00e8 che una riga di codice non dovrebbe mai essere ripetuta due volte. In pratica, questo non \u00e8 sempre possibile, ma per il bene della chiarezza, dovreste sempre pensare a come ridurre la ripetizione.<\/p>\n
In maniera simile, lo stesso pezzo di dati non dovrebbe esistere in pi\u00f9 di una variabile. Se state definendo lo stesso pezzo di dati in pi\u00f9 posti, avete decisamente bisogno di una classe. Oppure, se vi trovate a passare dei riferimenti allo stesso elemento HTML a pi\u00f9 funzioni, il riferimento dovrebbe probabilmente essere una propriet\u00e0 in un’istanza di una classe.<\/p>\n
Gli oggetti possono anche essere messi dentro ad altri oggetti per aumentare ulteriormente la cohesion. Per esempio, potreste mettere tutte le funzioni AJAX in un singolo modulo che includa oggetti per l’invio di form, per prendere il contenuto e la sintassi di login, cos\u00ec:<\/p>\n
Ajax.<\/span>Form.<\/span>submitForm(<\/span>)<\/span>;<\/span>\nAjax.<\/span>Content.<\/span>getContent(<\/span>7<\/span>)<\/span>;<\/span>\nAjax.<\/span>Login.<\/span>validateUser(<\/span>username,<\/span> password)<\/span>;<\/span><\/code><\/pre>\n
Al contrario, non dovreste mettere insieme cose non collegate nella stessa classe. Un’agenzia per cui ho lavorato aveva una API interna con un oggetto chiamato Common<\/code> che aveva un miscuglio di metodi e variabili comuni che non avevano nulla a che fare tra loro. La classe era diventata enorme e poco chiara semplicemente perch\u00e9 non si era pensato alla cohesion.<\/p>\n
Se le propriet\u00e0 non sono usate da molteplici metodi in una classe, questo pu\u00f2 essere un segno di bassa o cattiva cohesion. In maniera simile, se i metodi non possono essere riutilizzati in alcune situazioni diverse, oppure se un metodo non \u00e8 usato per niente, anche questo pu\u00f2 essere un segno di bassa o cattiva cohesion.<\/p>\n
La high cohesion aiuta ad alleviare il tight coupling e il tight coupling \u00e8 un segno che occorre una cohesion maggiore. Se i due entreranno mai in conflitto, tuttavia, scegliete la cohesion. High cohesion \u00e8 generalmente un aiuto maggiore per lo sviluppatore rispetto al coupling, sebbene entrambe possano solitamente essere ottenute assieme.<\/p>\n
\n
Conclusione<\/h2>\n
Se il nostro codice non \u00e8 immediatamente chiaro, ci saranno dei problemi. Ottenere la chiarezza richiede molto pi\u00f9 di un’appropriata indentazione: ci vuole una pianificazione fin dall’inizio del progetto. Sebbene sia difficile da padroneggiare, rispettare il principio di singola responsabilit\u00e0, la command-query separation, il loose coupling e la high cohesion pu\u00f2 migliorare notevolmente la chiarezza del nostro codice, cosa che dovrebbe essere presa in considerazione in ogni progetto di programmazione significativo.<\/p>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
Ci\u00f2 che separa i grandi sviluppatori da quelli bravi \u00e8 il fatto di scrivere sempre codice il pi\u00f9 chiaro possibile. Elimina la confusione, riduce i mal di testa per gli attuali e i futuri developer e fa risparmiare tempo a tutti sul lungo periodo. E sebbene non sia sempre facile come sembra, con una buona programmazione in ottica futura, con un approccio logico alla struttura del codice e con l’adesione ad alcuni principi guida, programmare con maggiore chiarezza \u00e8 qualcosa alla portata di tutti gli sviluppatori.<\/p>\n","protected":false},"author":818,"featured_media":7000833,"comment_status":"open","ping_status":"open","template":"","categories":[269,271,207],"tags":[],"coauthors":[497],"class_list":["post-803","article","type-article","status-publish","has-post-thumbnail","hentry","category-application-development","category-javascript","category-numero-229-2-novembre-2017"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article\/803","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article"}],"about":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/types\/article"}],"author":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/users\/818"}],"replies":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/comments?post=803"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media\/7000833"}],"wp:attachment":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media?parent=803"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/categories?post=803"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/tags?post=803"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/coauthors?post=803"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
(Vedi la app completa qui<\/a>)<\/p>\n