Le pratiche ingegneristiche sono il sottoinsieme delle pratiche descritte nei libri di eXtreme Programming che hanno direttamente a che fare con le modalità con cui si scrive/progetta/verifica il software. Esse sono: - il Simple Design - il Test-Driven Development - la Continuous Integration - il Refactoring, e - il Pair Programming. Sono famose di nome, ma non sempre è possibile venire a contatto con una loro definizione corretta, ed è facile farsi un'idea sbagliata di cosa siano e trovare problemi ad applicarle in modo efficace alla propria situazione. Spiegherò come ognuna di queste pratiche possono aiutarci nello sviluppo software portando esempi presi dal mio lavoro quotidiano o dal lavoro di altre persone con cui sono venuto in contatto.

1. @andreafrancia
Introduzione alle
pratiche ingegneristiche
di eXtreme Programming
Andrea Francia
Agile Day(s) 2018 a Brescia
10 novembre 2018

2. @andreafrancia
Chi sono

3. Sono un programmatore da
tanto tempo

4. @andreafrancia
Faccio cose

5. Trovo comodo usare i test
automatici per lavorare

6. Occasionalmente faccio il
coach (di TDD)

7. Conduco il TDD Milano

8. Ho un progetto open source

9. Ho cambiato un sacco di
aziende

10. @andreafrancia
Mi ero fatto un idea di cosa
fosse l’ingegneria del software

11. @andreafrancia
Ma poi …

13. @andreafrancia
Test >
Documentazione

14. @andreafrancia

15. @andreafrancia
Cos’è XP?

16. @andreafrancia

17. @andreafrancia
Quanti ce ne restano?
Survived ?
Survived !

18. @andreafrancia
Scrum

19. @andreafrancia
Scrum in breve
(secondo me)
• Team crossfunzionali
• Team che si auto organizzano
• Rilasci incrementali
• Timeboxing (1 settimana o più)
• Pianificazione continua
• Plan-Do-Check-Act

20. @andreafrancia
XP Scrum
(about programming) (anything)
Iterations Sprints
Planning Game Sprint Planning Meeting
Stories/Cards Product Backlog Items
Not so fixed Fixed Sprint Backlog
Engineering Practices See XP
Engineering Practices: TDD, Pair Prorgramming, Simple Design, Refactoring

21. @andreafrancia
XP ❤ Scrum
https://medium.com/agile-outside-the-box/better-together-xp-and-scrum-c69bf9bffcff

22. @andreafrancia
Scrum + Technical
practices ≈ XP

23. @andreafrancia
Scrum - Technical
practices = ?

24. @andreafrancia

25. @andreafrancia
Come vanno le cose
in un progetto XP?

26. @andreafrancia
In un progetto XP …
• In ogni momento c’è un sistema funzionante (*) &&
• Periodicamente al sistema vengono aggiunte nuove
feature (*) &&
• Non ci sono regressioni (*) &&
• Il sistema risolve un problema del cliente <— (oggi non ne
parliamo però)
(*) in produzione

27. @andreafrancia
Per ottenere questi risultati
i programmatori impiegano
le pratiche di XP

28. @andreafrancia
Quali sono le pratiche
ingegneristiche?

34. @andreafrancia
Quante sono le 12 pratiche XP?
12!
1999
13! 2002
13! 24!
2004

35. @andreafrancia
~50
Quante sono le 12 pratiche XP?

36. @andreafrancia
Le pratiche
ingegneristiche (*)
(*) solo le classiche

37. @andreafrancia
Pair Programming – tutto il codice di
produzione è scritto da due
programmatori che lavorano sullo
stesso computer.

38. @andreafrancia
Simple Design – il sistema viene
mantenuto il più semplice possibile
rimuovendo ogni complessità non
appena scoperta.

39. @andreafrancia
Testing – i programmatori scrivono
continuamente nuovi unit test che devono sempre
passare tutti perché lo sviluppo possa continuare.
Anche i clienti scrivono test. I test dei clienti
devono dimostrare che una feature è conclusa.

40. @andreafrancia
Refactoring – i programmatori ristrutturano
il sistema senza cambiarne il
comportamento per: rimuovere
duplicazione, migliorarne l’espressività, per
semplificarlo, or per aggiungergli flessibilità.

41. @andreafrancia
Collective Ownership – Chiunque, in
ogni momento, e dovunque nel sistema
può modificare il codice.

42. @andreafrancia
Continuous integration – il sistema
viene integrato e ricostruito più volte al
giorno, ogni volta che si finisce un task.

43. @andreafrancia
Coding standards – i programmatori
scrivono tutto il codice in accordo a
delle regole che supportino la
comunicazione attraverso il codice.

44. @andreafrancia
La mia esperienza
con le pratiche

45. @andreafrancia
Pair Programming

46. @andreafrancia
L’antenato del pair
programming è la
revisione tecnica formale.

47. @andreafrancia
8 ore di pair
programming sono
troppe (*)

48. @andreafrancia
Come lo posso introdurre
nel mio team?
• Non chiedete il permesso di fare Pair Programming.
• Quando c’è qualcosa di difficile da fare chiedete aiuto.
• Quando c’è qualcuno in difficoltà offrigli il tuo aiuto.

49. @andreafrancia
Pair Programming e
produttività
• Uno per minare la produttività di un team è dare obiettivi
diversi ad ogni membro del team.
• Gli obiettivi di team dovrebbero essere ordinati per priorità
e non assegnati alle singole persone.
• Tutti i membri del team dovrebbero auto-organizzarsi per
chiudere prima i task a più alta priorità

50. @andreafrancia
Pre-requisiti e aiuto
• Codice Condiviso (tra tutto il team)
• Priorità sui task condivisa
• Credere che far rivedere il codice ad un altra persona
abbia un valore

51. @andreafrancia
Dove venire a sperimentarlo
• Global Day of Code Retreat (17 novembre 2018)
• https://www.coderetreat.org/
• Incontri del vostro XPUG (o del TDD Milano)

52. @andreafrancia
Collective Code Ownership
• Tutto il codice codice appartiene al progetto, non al
singolo programmatore.
• Se una coppia incontra un pezzo di codice che può
essere migliorato lo migliora.
• Se una coppia ha bisogno di modificare un pezzo di
codice per implementare una feature lo modifica.

53. @andreafrancia
Coding Standards

54. @andreafrancia
La pratica più
fastidiosa, o forse no?

55. @andreafrancia
Non è solo una questione
di graffa su o graffa giù.

56. @andreafrancia

57. @andreafrancia
Coding Standards
• I programmatori si accordano su uno standard di sviluppo
condiviso e accettato volontariamente.

58. @andreafrancia
Non è necessario
scrivere un documento!

59. @andreafrancia
Tradizione orale +
“buon” esempio

60. @andreafrancia
Esempi di regole che
abbiamo usato
• Dividere i commit di Refactor da quelli di cambio del
comportamento
• Committare solo in verde
• Committare spesso in verde
• Mai cambiare la formattazione di un file che alla fine non
andava modificato
• End-of-line alla fine del file
• Tastiera US -vs- International o italiana

61. @andreafrancia

62. @andreafrancia
Testing automatico

63. @andreafrancia
Pratica utile
indipendentemente da
XP

64. @andreafrancia
È l’alternativa al
debugging disperato

65. @andreafrancia
È indispensabile per il
refactor

66. @andreafrancia
“non puoi sempre
metterci un taccone”

67. @andreafrancia
“hai cambiato un
codice che funzionava!”

68. @andreafrancia
“se non è rotto non
aggiustarlo!”

69. @andreafrancia
I framework xUnit ci sono
per qualsiasi linguaggio

70. @andreafrancia

71. Se non ci sono si creano

72. Two kind of tests
• unit test written by the programmers to convince
themselves that their programs work the way they think
the program work.
• functional tests written by (or at least specified by) the
customers to convince themselves that the system as a
whole works the way they think the system as a whole
should work.
eXtreme Programming explained 1st ed - Kent Beck - p. 47

73. @andreafrancia
Da dove iniziare?

74. @andreafrancia
Fate 20 minuti di pratica
ogni mattina con jUnit,
fate un kata

75. @andreafrancia
Andate a (o fondate)
un meetup sul TDD

76. @andreafrancia
Non chiedete al
management di poter
testare

77. @andreafrancia
Al posto di fare il debug a
mano fate dei main()
alternativi

78. @andreafrancia
Quando vi chiedono di
aggiustare un baco scrivete
prima un test che lo verifica

79. @andreafrancia
Design incrementale

80. @andreafrancia
Design incrementale
• Si evita il Big Design Up Front
• Nel codice è presente solo quanto design basta per
soddisfare i requisiti correnti.
• Il design del sistema è il più semplice possibile, si toglie il
superfluo. (semplice non vuol dire facile)
• Quando il design a disposizione non è più sufficiente ne
iniettiamo dell’altro.

81. @andreafrancia
Simple Design
Ad un dato momento il giusto design per un software è
quello che:
1.Fa passare tutti i test.
2.Non contiene logica duplicata
3.Rende chiaro il motivo per è stato scritto
4.Contiene il numero minimo di elementi

82. @andreafrancia
Usare il simple design
per valutare un refactor

83. @andreafrancia
Se un refactor non
migliora il design si butta

84. @andreafrancia
Refactor

85. @andreafrancia
È l’unico modo che
abbiamo per iniettare
design nel codice

86. @andreafrancia
Se non hai test te lo
sogni, non hai idea di
dove puoi arrivare

87. @andreafrancia
Una volta facevo
refactor senza test…

88. @andreafrancia
Refactor e test lenti

89. @andreafrancia
Architettura
esagonale

90. @andreafrancia
Anche i test chiedono
il refactor

91. @andreafrancia
Quando fare refactor?

92. @andreafrancia
Refactor prima
• “When implementing a program feature, the programmers
always ask if there is a way of changing the existing
program to make adding the feature simple.”

93. @andreafrancia
Mikado Method
http://www.methodsandtools.com/archive/mikado.php

94. @andreafrancia
Refactor dopo
• Dopo aver aggiunto una feature i programmatori si
chiedono se riescono a vedere dei modi per rendere il
programma più semplice (i test intanto devono continuare
a funzionare)

95. @andreafrancia
Refactor per semplificare (1)
• Si può aumentare l’espressività del codice, esempi:
• aggiungere nomi
• migliorare nomi
• promuovere simmetria

96. @andreafrancia
Refactor per semplificare (2)
• Si può rimuovere codice superfluo:
• rimuovendo la duplicazione
• rimuovendo codice non usato
• rimuovendo sovrastrutture che ora non servono più

97. @andreafrancia
Quando il sistema chiede
Refactor?
• Quando c’è della duplicazione
• Quando è difficile mettere sotto test una classe o un
metodo
• Quando modifichi un comportamento e poi si rompono N
test
• Quando provando a raccontare cosa fa il codice ad un
altro programmatore ti accorgi di usare parole diverse da
quelle nel codice

98. @andreafrancia
Test-First

99. @andreafrancia
Test-First ≠ TDD

100. Why Test First?
• The test gives me a chance to think about what I want
independent of how it will be implemented.
• Then the test tell me if I implement what I thought I
implemented.

102. @andreafrancia
Test-Driven
Development

103. @andreafrancia
Gli ingredienti di TDD
• Lo sviluppo è incrementale
• I test scritti prima del codice (Test First)
• Il design applicato in maniera incrementale e continua
(Incremental Design)

104. @andreafrancia
Pseudo-TDD
• Penso ad una soluzione
• Mi immagino un insieme di classi e funzioni che so che avrò
bisogno di creare
• Scrivo qualche test che ne verifica l’esistenza
• Lancio tutti i test e li vedo fallire
• Implemento un po’ di roba
• Lancio tutti i test e li vedo fallire
• Vado di debug duro
• Lancio tutti i test e passano
• (Opzionale) Da qualche parte mi metto un TODO dicendo di
ritornare a pulire più avanti

105. @andreafrancia
Il ritmo del TDD
1. aggiungi velocemente un test
2. lancia tutti i test, vedi quello nuovo fallire
3. fai una piccola modifica
4. lancia tutti i test, vedi che tutti passano
5. fai refactor per rimuovere la duplicazione
Test Driven Development: By Example by Beck, Kent

106. @andreafrancia
La TODO list
http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/
KentBeck_TDD_byexample.pdf

107. @andreafrancia
Le tre leggi del TDD
1. Non ti è permesso scrivere codice di produzione a meno
che non sia per fare passare un test che sta fallendo.
2. Non ti è permesso aggiungere codice ad un test più di
quello che sia sufficiente a farlo fallire; e gli errori di
compilazione contano come fallimenti.
3. Non ti è permesso aggiungere più codice di produzione
di quello che sia sufficiente per far passare un test che
fallisce.

108. @andreafrancia
I colori del TDD
1. Parti pulito
2. Aggiungi velocemente un test, lancia tutti i
test e vedi fallire quello nuovo
3. Fai una piccola modifica (al codice di
produzione), lancia tutti i test e vedi che ora
passano tutti
4. Un passo alla volta rimuovi tutta la
duplicazione, ad ogni passo lancia i test e
vedili passare tutti. (Refactor)
FAIL
PASS
PASS
PASS
PASS
PASS
…

109. @andreafrancia
Il refactor in TDD
all tests
passing
one
failing
test
Aggiungi velocemente un test
Fai una piccola modifica
al codice di produzione
Refactor

111. When refactor?

112. Test lenti e test veloci

114. Michael Feathers. 2004. Working Effectively with Legacy Code. Prentice Hall

115. Michael Feathers. 2004. Working Effectively with Legacy Code. Prentice Hall

116. What is not unit test?
A test is not a unit test if:
1.It talks to a database.
2.It communicates across a network.
3.It touches the file system.
4.Requires some manual set-up
Working Effectively with Legacy Code - Michael Feathers

117. Michael Feathers. 2004. Working Effectively with Legacy Code. Prentice Hall

118. • fast
• reliable
• slow
• fragile

119. http://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid

120. @andreafrancia
Continuous
Integration

122. @andreafrancia
Continuous
Integration ≠ Jenkins

123. @andreafrancia
Continuous
Integration ≠ Git Flow

124. @andreafrancia
Continuous Integration
≠ merge da master

125. @andreafrancia
Cosa vuol dire integrare
due linee di sviluppo?

126. @andreafrancia
I problemi di integrazione
crescono in modo super
lineare con il tempo

127. @andreafrancia
I problemi di integrazione
crescono con la
dimensione della codebase

128. @andreafrancia
Integrazione continua
applicata alle dipendenze

129. @andreafrancia
Daily deployment
(una specie di
integrazione continua)

130. Il rosso giusto

135. @andreafrancia
Grazie
Vorresti che lavorassi per te?
Chiamami
+39 3209437233