Download - BDD & design paradoxes appunti devoxx2012
Design Paradoxes & BDDappunti dal Devoxx2012 di Nicola Pedot
Paradosso 1: la flessibilità genera complessità
La rovina proviene dalla volontà di eccessiva flessibilità, la chiave sta nel trovare la giusta misura evitando quella non richiesta.
BDD e una corretta modularizzazione aiutano in questo. Poi vedremo....
Paradossi derivati[fonte link1]
Paradosso 2: il riuso complica l'uso
Il Graal del riuso promesso da sviluppo orientato all'oggetto ('80), al componente ('90) ed al servizio ('00) è elusivo.
Vale il Principio di Equivalenza Riuso-Rilascio di Robert Martin [1]"La granularità del riuso è la granularità del rilascio."
Paradosso 2: termine granularità
Paradosso 2: termine granularità
Si parla di granularità per indicare come un entità si divida in parti. Un'entità a granularità grossa, godrà di maggiori capacità in virtù delle singole capacità che include, ma avrà maggiori dipendenze con le sue parti.
"Entità a granularità più grossa sono più facili da usare, mentre quelli a granularità più piccola sono più facili da riusare"
Paradosso 2:termine peso
Paradosso 2:termine peso
Si parla di peso dell'entità per indicare la quantità di dipendenza con il contesto in cui vive. Un entità dal peso maggiore avrà maggior dipendenza dal contesto e minor necessità di configurazione.
"Entità a peso maggiore saranno più facilmente usabili, entità a peso minore saranno più facilmente riusabili."
Paradosso 2: quizgranularità e peso
Entità
Contesto
Parte
Paradosso 3: l'evoluzione blocca la sopravvivenza
Quando iniziate un nuovo progetto lo pensate modulare e flessibile per allungargli la vita. Il tempo metterà a dura prova questo pensiero.Lo stratificarsi di hack porterà il sistema ad un ambiente difficile in cui vivere e mantenere. Il debito tecnico è destinato a crescere.
Paradosso 3definizione di debito tecnico (1)
"Debito tecnico" introdotta da Ward Cunningham più o meno così:
"l'insieme dei compromessi di progettazione che accettiamo per rispettare le scadenze e soddisafare i clienti."
Paradosso 3definizione di debito tecnico (2)
"Debito tecnico" spiegato da Martin Fowler con un parallelo economico più o meno così:
"Come un debito economico, col tempo un debito tecnico chiede il pagamento di interessi in forma di maggior sforzo legato a scelte veloci e sporche. Possiamo scegliere di pagare gli interessi o di pagare un prezzo di riscatto applicando refactoring."
Il debito che portiamo
Il debito che cresce
Paradosso 3:legge dell'incremento di complessità
Meir M. Lehman's [2]:Con l'evoluzione di un sistema la sua complessità cresce a meno di lavoro per mantenerla costante o ridurla.
Strategie per contrastare il debito e cercare la giusta flessibilità
Controllare le dipendenze di grana e peso in modularizzazione a tutti i livelli.
[Link1]
Architettura a tutti livelli[fonte link1]
Attrezziamoci
Strumenti
Sonarhttp://www.sonarsource.org/
Permette di misurare le dipendenze, la complessità e il debito tecnico.
Metodologia Behavior Driven Development (BDD)
Definire un linguaggio comune tra: clienti, analisti, sviluppatori e tester.
Partire dalle richieste del cliente e investigando per scoprire le VERE richieste per poi implementare solo quelle che portano valore e con il minimo sforzo.
L'uso dei test di accettazione
Nello sviluppo si intende incluso anzi si concorda con il cliente il test che assume valore di contratto.
I test automatizzati devono essere espressi e leggibili anche dal cliente.
5 Guadagni
1. Quanto è implementato è ciò che porta vero valore al cliente.
2. Meno lavoro sprecato.3. Miglior comunicazione.4. Miglior qualità del codice.5. Tracciabilità dei requisiti e del
valore associato al codice.
La piramide della tracciabilità[fonte link2]
Organizzazione degli Artefatti[fonte link2]
Strumenti di acceptance test
Una moltitudine da scegliere in base al contesto di lavoro/preferenze... tra questi:● jbehave (java)● cucumber (ruby)● easyb (groovy)● jasmine (javascript)● thucydides● spec2● spock
il complemento del BDD è il Test Driven Development (TDD) [fonte link2]
Che dovremmo conoscere...ma non è così facile [fonte link2]
Grazie
per l'attenzione
Link
[1] Paradoxes of Software Architecture
by Kirk Knoernschild
goo.gl/Mcpcl
[2] Bdd state-of-the-union
by John Smart
goo.gl/XZWxl
Riferimenti
[1] Robert C. Martin, "Design Principles and Design Patterns." January 2000.
[2] Meir M. Lehman, "On Understanding Laws, Evolution, and Conservation in the Large-Program Life Cycle." Journal of Systems and Software Vol. 1, 1980, pp. 213