Written by 00:29 API Design

KISS Principle

Per spiegare il principio KISS partiamo dal suo acronimo che, nel corso del tempo, ha assunto un buon numero di varianti, ma che in origine stava per: “Keep It Simple, Stupid“. Un acronimo che risuona quasi come un imperativo a non complicare ulteriormente i problemi. Viceversa, si dovrebbero formulare soluzioni quanto più semplici e lineari possibile, procrastinando eventuali ottimizzazioni a successive fasi di sviluppo.

Everything should be made as simple as possible, but no simpler.

Albert Einstein

Quante varianti?

Come dicevamo, si è rimuginato talmente tanto sul KISS che, a dispetto della semplicità della quale si fa portavoce, sono nate svariate altre varianti per il suo nome:

  • Keep It Simple, Stupid. L’originale e… offensiva versione.
  • Keep It Stupid Simple. Variante proposta a favore dei molti che si sono sentiti offesi dallo “stupid“. Qui l’attributo viene spostato ed applicato ad un altro soggetto: il codice. Come a voler chiarire che si dovrebbe scrivere in modo talmente semplice da risultare comprensibile a chiunque.
  • Keep It Sweet and Simple. La variante carina e coccolosa, per i più romantici.
  • Keep It Short and Simple. La variante che più apprezzo, sopratutto quando vedo metodi o classi dalle troppe loc.
  • Keep It Simply Smart. E non poteva mancare la variante dei tempi moderni!

Non è un caso, però, che tutti gli acronimi abbiano la parola simple al loro interno.

In sostanza… di cosa si tratta?

In poche parole si tratta di semplicità, ma ottenerla non è affatto semplice.

Tipicamente quando uno sviluppatore si trova faccia a faccia con un problema, un approccio comune alla risoluzione sta nel divide et impera. Questo si traduce nel tentativo di gestire la complessità cercando di frammentare in parti sempre più piccole ed atomiche il problema.
Atomico è sinonimo di semplice: semplice da capire, semplice da testare, semplice da manutenere e con maggiori possibilità di essere riutilizzabile.
Eppure, dalla mia esperienza, la maggior parte dei programmatori non solo non effettua questa divisione sistematica ma, come aggravante, mette l’acqua a bollire nel pentolone e prepara dell’ottimo spaghetti code.
Codice che, magari farà anche bene il suo dovere, ma sarà come leggere una delle sentenze infinite di Cicerone dove ben prima di arrivare a metà, si perde il filo del discorso!
Se anche tu hai mai visto metodi (magari non scritti da te) di centinaia di righe di codice all’interno di classi che vanno oltre le mille righe, ed hai cercato di interpretare cosa facessero, certamente starai capendo cosa voglio dire. E certamente avrai avuto i miei stessi mal di testa.

Come applico il KISS?

Applicare il KISS non è qualcosa che si può spiegare in poche parole. Esistono tante prassi di buona programmazione da seguire. Prassi che, messe tutte insieme, potrebbero risultare ostiche in principio. Cercherò, quindi, di fare giusto una panoramica generale.

Simplicity is the ultimate sophistication.

Leonardo Da Vinci

Partiamo con lo sfatare falsi miti: cervellotico non vuol dire geniale, ed essere umili non ci declassa a programmatori scadenti. Anzi, l’umiltà insieme alla pazienza sono i punti di partenza.
Occorre umiltà nello scendere dal piedistallo del genio e smorzare ogni velleità di intraprendere quella soluzione iperbolica che solo la più contorta delle nostre personalità riesce ad interpretare. Piuttosto, il codice deve essere talmente stupido che persino dopo una settimana lavorativa da 80 ore e con ridottissime energie mentali riusciamo a capirlo.
Ed occorre pazienza per applicare sistematicamente un minuzioso refactoring del codice per frazionarlo in pezzi via via più semplici. Task complessi suddivisi in sotto-task; sotto-task smembrati in classi con singole responsabilità; classi piccole con metodi che assolvono compiti semplici e non superano le 10/20 linee di codice; spezzoni riutilizzabili spostati in classi di utility; complessità ciclomatica abbattuta; maggiore leggibilità del codice tramite un buon uso dei nomi dei metodi e delle variabili; un parco e sapiente utilizzo dei commenti (lasciamo parlare il codice).
I più complessi algoritmi sono costruiti assemblando insieme un mare di piccoli step.
All’inizio può sembrare controproducente perché ci porta via decisamente più tempo, ma i vantaggi, alla lunga, superano qualunque effort.
Ritornare dopo mesi su di una funzionalità dimenticata e contestualizzarla in pochi secondi? Impagabile.
Risolvere un bug in pochi minuti e con poche modifiche perché confinato all’interno di un metodo che ha poche istruzioni? Appagante.
Ma questi non sono gli unici benefici.

Quali sono i benefici?

In estrema sintesi potremmo elencare questi benefici:

  • maggiore qualità del codice prodotto.
  • codice più semplice da manutenere; più flessibile e facile da estendere, modificare, migliorare.
  • più semplice fare un passaggio di consegne anche all’ultimo arrivato nel progetto (il codice è stupido!). Ricordiamo che dovremmo sempre scrivere pensando di dover lasciare in eredità le nostre classi ad un killer psicopatico che, per giunta, sa dove abitiamo.
  • metodi più proni al riutilizzo (almeno in parte);
  • nessun mal di testa da spaghetti code.
(Visited 36 times, 1 visits today)
Close