The great power of Nothing

Neverending story!

In this historical moment with this global situation in the “pandemic world”, I saw most people doing some things without sense. One of the things that I did, thinking I was also doing something without sense, was to watch again “The neverending story” movie by Michael Ende. At first I was watching it like a story for children, in the same mode of when I was young. But at some point of the story, during the conversation between the Bad Gmork and the Warrior Atreyu, I had an intuition: maybe the movie wasn’t for children at all, but it was a hidden deeper message for humanity. [Read More]

Syndrome of the Framework Developer

If the only tool you have is hammer, you tend to see every problem as a nail! Abraham Maslow

“Software developer because superhero isn’t an official job title” After a little experience in software, sometimes as Developer we feel like superheroes (and we are!); maybe that happens after reading a book about design patterns, clean code, following blogs, twitter or famous people known in a conference; but we forget completely that we have our own brain, and then the most import thing: the context of our product! [Read More]

Sindrome da Framework Developer

Se l'unica cosa che hai è un martello tratterai tutto come se fosse un chiodo!

Dopo un pò di esperienza noi sviluppatori ci sentiamo come i supereroi, iniziamo qualche lettura di libri su design patterns, clean code, seguire blog, twitter o personaggi famosi conosciuti durante qualche conferenza; dimenticando completamente di avere un proprio cervello da usare, e di un’altra cosa molto importante, ovvero: il contesto in cui ci troviamo ed il nostro tipo di prodotto!!! Presi dall’entusiasmo iniziamo a pensare a tutto con design patterns ed a sviluppare qualsiasi cosa pensando come se fosse un framework. [Read More]

Metodi imbuto

Faccio tutto io!

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]

Ereditarietà VS Composizione

Inheritance VS Compositioning

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]

Open-Closed

Open-Closed.

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]

Single Responsibility

Single Responsibility.

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]

I principi SOLID

I principi SOLID.

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]

Broken windows

La teoria delle finestre rotte.

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]

Boy Scout Rule!

Always leave the campground cleaner than you found it.

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]