Articoli di programmazione
I 3 principi DRY, KISS, and YAGNI
Cosa sono i 3 principi DRY, KISS, and YAGNI e come possono aiutarci a scrivere codice migliore
Nel mondo della programmazione esistono molte regole e principi che se seguiti, portano senza dubbio a programmi migliori, codice pulito e sistemi altamente manutenibili. Spesso questi principi sono semplici regole di buon senso ma non tutti le seguono. Facciamo un ripassino veloce insieme.
Tre principi sono molto importanti e da tenere sempre presenti quando si scrive codice:
- DRY: Don't repeat yourself
- KISS: Keep it simple stupid
- YAGNI: You aren't gonna need it
DRY: Don't repeat yourself
Non ripeterti!
Partiamo dal fatto che ogni logica applicativa debba avere una ed una sola rappresentazione nel nostro sistema. Questo significa che dobbiamo scrivere piccole classi molto specializzate, con semplici e piccoli metodi modulari, contenenti la logica applicativa da riutilizzare ovunque serva.
Non ripeterti vuol dire che non devi ripetere il codice che hai già scritto. Se ti trovi a fare copia e incolla di qualche porzione di codice tra una classe e l'altra, con tutta probabilità stai violando questo principio. Cerca piuttosto di isolare il codice che hai copiato, in un metodo o in una sua classe e chiamalo da entrambi i punti in cui ti serve, dopo aver re-ingegnerizzato tramite #refactoring le classi in gioco.
KISS: Keep it simple stupid
Lascialo semplice, stupido!
Codice semplice e lineare significa codice migliore:
- maggiore produttività perché ogni modifica è più rapida, dato che è tutto chiaro e ben individuabile
- maggiore robustezza perché meno incline ad errori, perché i bug si individuano più rapidamente
- minori costi, perché banalmente si fa prima a scriverlo, comprenderlo e modificarlo
- maggiore flessibilità nelle pianificazioni, perché rende possibile maggiore condivisione nel Team e quindi interoperabilità tra i programmatori
Il codice che scrivi deve essere comprensibile e semplice, perché con tutta probabilità verrà manutenuto da altri che quindi dovranno capirlo il più rapidamente possibile per fare bene il loro lavoro.
Quante volte capita di vedere classi di migliaia di righe, con metodi di centinaia di righe?
Quante volte si trovano #Switch-Case intrecciati con #Loop annidati in mezzo a #If-Then-Else mal-formattati?
Quante volte capita di prendere in mano un progetto e trovare metodi criptici, senza neanche mezzo commento, in cui letteralmente la complessità del codice non permette di capire cosa quella determinata classe stia facendo?
Ebbene: KISS!
Scrivi classi piccole e semplici, con metodi costituiti da poche righe, che fanno una cosa sola.
Non devi per forza mostrare agli altri programmatori quanto conosci bene i meandri della sintassi del linguaggio: scrivi codice lampante e semplice, non costruire sistemi eccessivamente complessi o illeggibili. Codificare significa comunicare, sia con la CPU che con gli altri programmatori. Documenta il tuo codice con commenti nei punti meno chiari.
YAGNI: You aren't gonna need it
Non ne avrai bisogno!
Quando si parte a scrivere un programma ci troviamo a scrivere le nostre classi. Per una determinata funzionalità solitamente iniziamo a scrivere una classe. Quando questa classe viene codificata, il programmatore deve decidere cosa includere: quali metodi e proprietà avrà questa classe, cosa dovrà fare al servizio del programma, quali esigenze avrà il programma in rapporto a questa classe. Ebbene in questa fase il programmatore tende a sovrastimare queste esigenze e di conseguenza codifica metodi e proprietà che in realtà non serviranno mai.
Credo che la parte del cervello che ci induce a far questo, sia la stessa che ci spinge a comprare prodotti in eccesso quando andiamo a fare la spesa al supermercato; lo facciamo con la certezza che tanto "servono e sicuramente li useremo", salvo poi trovarli scaduti nella dispensa qualche tempo dopo.
Per quanto banale possa sembrare, questo è un grande problema che causa grande spreco e inefficienza in ambito software.
Scrivere codice che non serve, rende il codice sovra-dimensionato e questo poi costituisce un fardello da portarsi dietro per tutta la vita dell'applicazione.
Giusto per essere chiari: stai perdendo tempo a scrivere e testare codice che non userai mai e che non serve. Dovrai manutenerlo e questo si tradurrà in un costo: stai generando enormi sprechi di risorse solo perché hai deciso di aggiungere quel metodo che, al momento non ti serve, ma sei sicuro che prima o poi ti servirà. Di fatto parti per scrivere una semplice applicazione e, se non segui YAGNI, ti trovi a progettare ed implementare un intero framework!
Per evitare questi sprechi spesso aiuta adottare un approccio Top-Down, cioè iniziare dalle parti più complesse, che stanno nella "parte alta" dell'architettura applicativa e quindi più "vicine all'utente", per sviluppare le parti meno complesse e nella "parte bassa" dell'applicazione successivamente. In questo modo si "disegna" quello che serve all'utente a successivamente si va implementare il codice che lo realizza.
Ma al di là dell'approccio "Top-Down o Bottm-Up", mentre scrivi ripetiti il mio lavoro non sarà finito quando avrò aggiunto tutto, ma solo quando avrò tolto tutto ciò che non è necessario.
Un altro ottimo metodo è sviluppare usando #TDD perché ci guida a sviluppare il minimo indispensabile, cioè solo i metodi per rendere verdi i nostri test.
Ricorda: scrivi il codice di cui hai bisogno adesso; non pensare al dopo e non cercare di prevedere il futuro; se avrai bisogno di altre funzionalità, le svilupperai successivamente: che problema c'è? Vivi per il presente e non pensare al futuro: entro certi limiti è anche una buona dottrina di vita :-)
#programmazione #codice
Tre principi sono molto importanti e da tenere sempre presenti quando si scrive codice:
- DRY: Don't repeat yourself
- KISS: Keep it simple stupid
- YAGNI: You aren't gonna need it
DRY: Don't repeat yourself
Non ripeterti!
Partiamo dal fatto che ogni logica applicativa debba avere una ed una sola rappresentazione nel nostro sistema. Questo significa che dobbiamo scrivere piccole classi molto specializzate, con semplici e piccoli metodi modulari, contenenti la logica applicativa da riutilizzare ovunque serva.
Non ripeterti vuol dire che non devi ripetere il codice che hai già scritto. Se ti trovi a fare copia e incolla di qualche porzione di codice tra una classe e l'altra, con tutta probabilità stai violando questo principio. Cerca piuttosto di isolare il codice che hai copiato, in un metodo o in una sua classe e chiamalo da entrambi i punti in cui ti serve, dopo aver re-ingegnerizzato tramite #refactoring le classi in gioco.
KISS: Keep it simple stupid
Lascialo semplice, stupido!
Codice semplice e lineare significa codice migliore:
- maggiore produttività perché ogni modifica è più rapida, dato che è tutto chiaro e ben individuabile
- maggiore robustezza perché meno incline ad errori, perché i bug si individuano più rapidamente
- minori costi, perché banalmente si fa prima a scriverlo, comprenderlo e modificarlo
- maggiore flessibilità nelle pianificazioni, perché rende possibile maggiore condivisione nel Team e quindi interoperabilità tra i programmatori
Il codice che scrivi deve essere comprensibile e semplice, perché con tutta probabilità verrà manutenuto da altri che quindi dovranno capirlo il più rapidamente possibile per fare bene il loro lavoro.
Quante volte capita di vedere classi di migliaia di righe, con metodi di centinaia di righe?
Quante volte si trovano #Switch-Case intrecciati con #Loop annidati in mezzo a #If-Then-Else mal-formattati?
Quante volte capita di prendere in mano un progetto e trovare metodi criptici, senza neanche mezzo commento, in cui letteralmente la complessità del codice non permette di capire cosa quella determinata classe stia facendo?
Ebbene: KISS!
Scrivi classi piccole e semplici, con metodi costituiti da poche righe, che fanno una cosa sola.
Non devi per forza mostrare agli altri programmatori quanto conosci bene i meandri della sintassi del linguaggio: scrivi codice lampante e semplice, non costruire sistemi eccessivamente complessi o illeggibili. Codificare significa comunicare, sia con la CPU che con gli altri programmatori. Documenta il tuo codice con commenti nei punti meno chiari.
YAGNI: You aren't gonna need it
Non ne avrai bisogno!
Quando si parte a scrivere un programma ci troviamo a scrivere le nostre classi. Per una determinata funzionalità solitamente iniziamo a scrivere una classe. Quando questa classe viene codificata, il programmatore deve decidere cosa includere: quali metodi e proprietà avrà questa classe, cosa dovrà fare al servizio del programma, quali esigenze avrà il programma in rapporto a questa classe. Ebbene in questa fase il programmatore tende a sovrastimare queste esigenze e di conseguenza codifica metodi e proprietà che in realtà non serviranno mai.
Credo che la parte del cervello che ci induce a far questo, sia la stessa che ci spinge a comprare prodotti in eccesso quando andiamo a fare la spesa al supermercato; lo facciamo con la certezza che tanto "servono e sicuramente li useremo", salvo poi trovarli scaduti nella dispensa qualche tempo dopo.
Per quanto banale possa sembrare, questo è un grande problema che causa grande spreco e inefficienza in ambito software.
Scrivere codice che non serve, rende il codice sovra-dimensionato e questo poi costituisce un fardello da portarsi dietro per tutta la vita dell'applicazione.
Giusto per essere chiari: stai perdendo tempo a scrivere e testare codice che non userai mai e che non serve. Dovrai manutenerlo e questo si tradurrà in un costo: stai generando enormi sprechi di risorse solo perché hai deciso di aggiungere quel metodo che, al momento non ti serve, ma sei sicuro che prima o poi ti servirà. Di fatto parti per scrivere una semplice applicazione e, se non segui YAGNI, ti trovi a progettare ed implementare un intero framework!
Per evitare questi sprechi spesso aiuta adottare un approccio Top-Down, cioè iniziare dalle parti più complesse, che stanno nella "parte alta" dell'architettura applicativa e quindi più "vicine all'utente", per sviluppare le parti meno complesse e nella "parte bassa" dell'applicazione successivamente. In questo modo si "disegna" quello che serve all'utente a successivamente si va implementare il codice che lo realizza.
Ma al di là dell'approccio "Top-Down o Bottm-Up", mentre scrivi ripetiti il mio lavoro non sarà finito quando avrò aggiunto tutto, ma solo quando avrò tolto tutto ciò che non è necessario.
Un altro ottimo metodo è sviluppare usando #TDD perché ci guida a sviluppare il minimo indispensabile, cioè solo i metodi per rendere verdi i nostri test.
Ricorda: scrivi il codice di cui hai bisogno adesso; non pensare al dopo e non cercare di prevedere il futuro; se avrai bisogno di altre funzionalità, le svilupperai successivamente: che problema c'è? Vivi per il presente e non pensare al futuro: entro certi limiti è anche una buona dottrina di vita :-)
#programmazione #codice