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. Se il progetto é piccolo e tende a restare così, potrebbe essere un buon modo per sperimentare approcci nuovi e trovare nuove strategie di sviluppo. Su progetti grossi o che tendono a diventare complessi in breve tempo, lavorare in questa modalità potrebbe essere molto pericoloso e creare quello che viene chiamato “Needless Complexity”.

Complicare qualcosa di semplice è sempre possibile, ma cosa succede, se il prodotto deve diventare complesso o dobbiamo aggiungere nuove funzionalità ad una parte dove abbiamo aggiunto complessità inutile? Diventa ingestibile in poco tempo ed il design molto rigido! Il codice diventa “Legacy Code” in breve tempo, la famosa “big ball of mud”.

È molto più semplice, evolvere il design di un’applicazione e trovare la giusta architettura man mano che la complessità aumenta, oppure durante il refactoring, separando il codice, creando layer nuovi ma al momento opportuno; piuttosto che tentare di mettere insieme qualcosa che è diventata complessa e sparsa inutilmente.

Un’altra cosa sovente di questa sindrome la si trova in un’estrema separazione dei concetti, ma poi il numero di riutilizzo delle funzioni non c’è! (attenzione non sto parlando della separazione dei metodi all’interno di un layer per favorire la lettura o ridurre la complessità di un metodo, piuttosto del codice sparso in centinaia di utils o servizi all’interno del progetto).

L’obiettivo principale dei design patterns (lo Strategy ad esempio) è creare un astrazione per favorire il riutilizzo del codice, riducendo le varie duplicazioni, ma se il riutilizzo non c’è, serve veramente scervellarsi inutilmente per un design, tentando di prevedere il futuro, per poi scoprire che questo design è sbagliato perché i requisiti futuri sono completamente diversi da quello che immaginavamo noi developer?

Avete mai guardato il codice del vostro framework/libreria preferito? È sempre così clean come pensate? Oppure seguono o hanno seguito un’evoluzione?

Non vi è mai capitato di farvi la domanda:

non capisco perchè in questa libreria non hanno implementato un determinato pattern?

Per poi vederlo apparire un anno dopo perché nel frattempo si é evoluta? A me personalmente sì, ed anche più volte!

Il caso più classico forse, è quello di immaginarsi qualcosa di molto complesso in principio, successivamente guardare il codice e pensare:

maah tutto qua??? Pensavo fosse molto più complesso di così ed invece…

Se vi riconoscete in questi sintomi (o conoscete qualcuno) significa semplicemente che vi manca l’esperienza e/o la parte “software craftsmanship”.

Da dove iniziare se vi trovate in questa situazione?

Ogni tanto fare uno sforzo maggiore nel non fare le cose sempre nello stesso modo per abitudine, ma cercare delle soluzioni alternative e migliori! Attenzione a non esagerare con l’opposto altrimenti vi ritrovate in questa sindrome.

Risorse utili:

Photo by MIOPS Trigger on Unsplash unsplash-logoMIOPS Trigger