Design Paradoxes & BDD
appunti dal Devoxx2012 di Nicola Pedot
Paradosso 1:
la flessibilità genera complessità
La rovina proviene dalla volontà di eccessiva
flessibilità, la chiave sta ...
Paradossi derivati
[fonte link1]
Paradosso 2:
il riuso complica l'uso
Il Graal del riuso promesso da sviluppo
orientato all'oggetto ('80), al componente ('...
Paradosso 2:
termine granularità
Paradosso 2:
termine granularità
Si parla di granularità per indicare come un
entità si divida in parti. Un'entità a granu...
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....
Paradosso 2: quiz
granularità e peso
Entità
Contesto
Parte
Paradosso 3:
l'evoluzione blocca la sopravvivenza
Quando iniziate un nuovo progetto lo pensate
modulare e flessibile per a...
Paradosso 3
definizione di debito tecnico (1)
"Debito tecnico" introdotta da Ward
Cunningham più o meno così:
"l'insieme d...
Paradosso 3
definizione di debito tecnico (2)
"Debito tecnico" spiegato da Martin Fowler
con un parallelo economico più o ...
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à ...
Strategie per contrastare il debito e
cercare la giusta flessibilità
Controllare le dipendenze di grana e peso in
modulari...
Architettura a tutti livelli
[fonte link1]
Attrezziamoci
Strumenti
Sonar
http://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....
L'uso dei test di accettazione
Nello sviluppo si intende incluso anzi si
concorda con il cliente il test che assume
valore...
5 Guadagni
1. Quanto è implementato è ciò che
porta vero valore al cliente.
2. Meno lavoro sprecato.
3. Miglior comunicazi...
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:
● jbehav...
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...
Riferimenti
[1] Robert C. Martin, "Design Principles and
Design Patterns." January 2000.
[2] Meir M. Lehman, "On Understan...
Upcoming SlideShare
Loading in …5
×

BDD & design paradoxes appunti devoxx2012

196 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
196
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

BDD & design paradoxes appunti devoxx2012

  1. 1. Design Paradoxes & BDD appunti dal Devoxx2012 di Nicola Pedot
  2. 2. 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....
  3. 3. Paradossi derivati [fonte link1]
  4. 4. 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."
  5. 5. Paradosso 2: termine granularità
  6. 6. 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"
  7. 7. Paradosso 2: termine peso
  8. 8. 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."
  9. 9. Paradosso 2: quiz granularità e peso Entità Contesto Parte
  10. 10. 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.
  11. 11. Paradosso 3 definizione 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."
  12. 12. Paradosso 3 definizione 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."
  13. 13. Il debito che portiamo
  14. 14. Il debito che cresce
  15. 15. 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.
  16. 16. Strategie per contrastare il debito e cercare la giusta flessibilità Controllare le dipendenze di grana e peso in modularizzazione a tutti i livelli. [Link1]
  17. 17. Architettura a tutti livelli [fonte link1]
  18. 18. Attrezziamoci
  19. 19. Strumenti Sonar http://www.sonarsource.org/ Permette di misurare le dipendenze, la complessità e il debito tecnico.
  20. 20. 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.
  21. 21. 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.
  22. 22. 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.
  23. 23. La piramide della tracciabilità [fonte link2]
  24. 24. Organizzazione degli Artefatti [fonte link2]
  25. 25. 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
  26. 26. il complemento del BDD è il Test Driven Development (TDD) [fonte link2]
  27. 27. Che dovremmo conoscere... ma non è così facile [fonte link2]
  28. 28. Grazie per l'attenzione
  29. 29. Link [1] Paradoxes of Software Architecture by Kirk Knoernschild goo.gl/Mcpcl [2] Bdd state-of-the-union by John Smart goo.gl/XZWxl
  30. 30. 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

×