BDD & design paradoxes   appunti devoxx2012
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

BDD & design paradoxes appunti devoxx2012

  • 196 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
196
On Slideshare
196
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Design Paradoxes & BDD appunti dal Devoxx2012 di Nicola Pedot
  • 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. Paradossi derivati [fonte link1]
  • 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. Paradosso 2: termine granularità
  • 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. Paradosso 2: termine peso
  • 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. Paradosso 2: quiz granularità e peso Entità Contesto Parte
  • 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. 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. 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. Il debito che portiamo
  • 14. Il debito che cresce
  • 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. 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. Architettura a tutti livelli [fonte link1]
  • 18. Attrezziamoci
  • 19. Strumenti Sonar http://www.sonarsource.org/ Permette di misurare le dipendenze, la complessità e il debito tecnico.
  • 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. 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. 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. La piramide della tracciabilità [fonte link2]
  • 24. Organizzazione degli Artefatti [fonte link2]
  • 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. il complemento del BDD è il Test Driven Development (TDD) [fonte link2]
  • 27. Che dovremmo conoscere... ma non è così facile [fonte link2]
  • 28. Grazie per l'attenzione
  • 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. 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