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:

1. 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.
2. 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!).
3. 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.