Il documento affronta diversi paradossi legati alla progettazione del software, evidenziando come la flessibilità possa generare complessità e come il riuso possa complicare l'uso. Viene discussa la natura del debito tecnico e la sua implicazione nell'evoluzione dei progetti, sottolineando che una buona modularizzazione e metodologie come il Behavior Driven Development (BDD) possono aiutare a gestire queste problematiche. Infine, si menzionano strumenti utili per misurare la complessità e il debito tecnico, enfatizzando l'importanza di una comunicazione chiara e della tracciabilità dei requisiti.

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