#Clean Code

Un problema ricorrente nello sviluppo sono le concatenazioni delle operazioni dove si finisce frequentemente nello stesso punto/metodo/funzione! Solitamente accade questo: si scrive una funzione e si inizia a riutilizzarla nei vari punti del progetto, man mano che la riutilizziamo si inizia ad aggiungere parametri, condizioni, codice nuovo che serve ad 8 dei 10 punti dove viene utilizzata ma nei 2 casi dove non serve passiamo booleane (con valori di default) per gestire queste eccezioni. [Read More]

Una domanda che affligge la nostra mente da developer da molti anni è questa: Devo ereditare o comporre? Ho sempre visto molta confusione su questo argomento tra programmatori io stesso mi ero trovato in questa situazione. Perché accade ciò? Provo a dare una spiegazione in base alla mia personale esperienza. Quando si passa da semplici “smanettoni” di codice a una programmazione più “seria” si inizia a leggere libri di Clean Code, seguire blog di tizio e caio, andare alle conferenze, eccetera. [Read More]

La O dei principi SOLID stà per Open Closed Principle (OCP), la sua definizione tradotta in italiano é la seguente: Una qualsiasi entità software (classe, modulo, funzione, ecc.) dovrebbe avere meccanismi che permettono di estenderne il comportamento senza apportare modifiche al codice preesistente. Quindi Aperte alle estensioni ma chiuse alle modifiche; da qui il nome Open-Closed. Questo insieme alla SRP è un’altro principio molto importante. Ma come si fa ad estendere una funzionalità senza modificare il codice esistente? [Read More]

La S dei principi SOLID stà per Single Responsibility Principle (SRP), la sua definizione tradotta in italiano é la seguente: Una classe dovrebbe avere uno ed unico motivo per cambiare Cosa significa? Significa avere classi più piccole ognuna con una sola responsabilità! Su molti testi si trova consigliato classi di dimensioni che non superano le 100-150 righe di codice al contrario delle “God class” dove ho una classe sola che “fa tutto”, invece il consiglio è di avere il codice dove non supera la schermata vedendo tutto senza dovere scrollare col mouse. [Read More]

Nei progetti informatici il software e la sua qualità degradano con il passare del tempo, si dice che il software marcisce (“Software Rots”). Questo degrado su molti testi di informatica viene descritto come “entropia del software”. A cosa é dovuto? La maggioranza dei progetti parte da un idea apparentemente “semplice”, ed é questa la “fregatura”, perché non resta mai così! Solitamente ad inizio attività partiamo sempre tutti con un buon design pensando: stavolta non sbaglio ! [Read More]

La teoria della finestra rotta è basata su un esperimento di psicologia sociale condotto nel 1969 dal professor Philip Zimbardo presso l’Università di Stanford. Egli mise due auto identiche abbandonate una nel Bronx e l’altra a Palo Alto. Quella nel Bronx venne smantellata nel giro di poche ore, mentre quella di Palo Alto rimase intatta. Allora i ricercatori decisero di fare un’altra prova rompendo un vetro del auto intatta e nel giro di poco tempo il risultato di degrado fu lo stesso di quella del Bronx. [Read More]

I boy scout americani hanno una regola/principio, lasciare il campo più in ordine di come lo si ha trovato inizialmente. Lo stesso principio è stato ripreso dallo “Zio Bob” Robert C. Martin il quale lo ha applicato al software nel seguente modo: Lasciate il codice più pulito di come lo avete ritrovato! Molte volte ci capita di riguardare parti del codice scritto in passato ed innorridire per la sua scarsa qualità! [Read More]