Quante volte siete tentati dal pensare in anticipo a tutte le potenziali future evoluzioni di una scelta architetturale o di codifica del vostro software?
Quante volte cedete a questa tentazione?
Quante volte questo approccio si rivela efficace?
Queste domande mi offrono l’occasione per parlarvi della regola KISS (Keep It Simple Stupid): falla semplice, stupido/a.
Dovrebbe essere una regola dettata dal buonsenso e dalla logica. Invece, troppo spesso si cade nella tentazione, in pieno delirio di onnipotenza, di predirre il futuro facendo delle assunzioni che potrebbero rivelarsi errate. Il dover pensare a tutte le possibili implicazioni di una scelta alla fine porta a sviluppare codice contorto, difficile da comprendere dopo pochi giorni anche per chi lo ha scritto, figuriamoci per chi lo deve manutenere.
Utilizzare soluzioni semplici offre grandi vantaggi: sono semplici da capire, sono semplici da manutenere e probabilmente sono soggette a meno errori nella loro realizzazione.
Ciò che va assolutamente evitato è l’approccio KICK (Keep It Complex Kamikaze).
E allora, vediamo quali sono le complicazioni da kamikaze che andrebbero evitate:
- Applicare pattern complessi troppo presto: se la funzionalità da implementare è ancora ad un livello di semplicità tale da non giustificare l’adozione di un design pattern probabilmente la soluzione più semplice è evitare di usarlo. Si potrà sempre decidere di applicare il pattern quando le condizioni muteranno.
- Eccedere nel progettare l’architettura del software per supportare potenziali richieste future: chi è in grado di predirre il futuro? Nessuno. Per tenere il software semplice basterà limitarsi a sviluppare le funzionalità richieste. E’ chiaro che nel corso dello sviluppo arriveranno altre richieste, che andranno valutate solo quando si presenteranno (ripetete con me: il futuro non si può predirre! il futuro non si può predirre! il futuro non si può predirre!).
- Sviluppare un’infrastruttura software complessa: spesso si cade nell’errore di lanciarsi nello sviluppo di gerarchie di classi o di interi framework sin dall’inizio di un progetto. Abbiamo veramente bisogno di sviluppare un sotto-sistema di logging o di interazione con il database sin dal principio, con il rischio che poi venga utilizzato poco (e vada comunque manutenuto)? Non è il caso di aspettare che diventi un’esigenza che aggiunga valore al software? Non è il caso di usare qualcosa di già pronto?
Spero di aver offerto uno spunto di riflessione. Proviamo, con uno sforzo di umiltà , a ripensare al nostro approccio nell’affrontare i problemi. Abbandoniamo l’orgoglio e gli esercizi stilistici e abbracciamo il KISS!
Fatemi sapere cosa ne pensate.
Penso che l’approccio KISS sia una metodologia molto valida ma sono in completo disaccordo sul fatto di “non usare pattern complessi troppo presto”.
I pattern semplificano lo sviluppo, rendono l’infrastruttura robusta, incentivano il riutilizzo del codice, tracciano le linee guida per gli sviluppi attuali e futuri e nobilitano il codice.
p.s. nessun pattern è complesso!!!
Ale, :D