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 …

12.
@andreafrancia
Test >
Documentazione

13.
@andreafrancia

14.
@andreafrancia
Cos’è XP?

15.
@andreafrancia

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

17.
@andreafrancia
Scrum

18.
@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

19.
@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

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

21.
@andreafrancia
Scrum + Technical
practices ≈ XP

22.
@andreafrancia
Scrum - Technical
practices = ?

23.
@andreafrancia

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

25.
@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

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

27.
@andreafrancia
Quali sono le pratiche
ingegneristiche?

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

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

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

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

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

33.
@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.

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

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

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

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

38.
@andreafrancia
La mia esperienza
con le pratiche

39.
@andreafrancia
Pair Programming

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

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

42.
@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.

43.
@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à

44.
@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

45.
@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)

46.
@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.

47.
@andreafrancia
Coding Standards

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

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

50.
@andreafrancia

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

52.
@andreafrancia
Non è necessario
scrivere un documento!

53.
@andreafrancia
Tradizione orale +
“buon” esempio

54.
@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

55.
@andreafrancia

56.
@andreafrancia
Testing automatico

57.
@andreafrancia
Pratica utile
indipendentemente da
XP

58.
@andreafrancia
È l’alternativa al
debugging disperato

59.
@andreafrancia
È indispensabile per il
refactor

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

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

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

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

64.
@andreafrancia

65.
Se non ci sono si creano

66.
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

67.
@andreafrancia
Da dove iniziare?

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

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

70.
@andreafrancia
Non chiedete al
management di poter
testare

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

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

73.
@andreafrancia
Design incrementale

74.
@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.

75.
@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

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

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

78.
@andreafrancia
Refactor

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

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

81.
@andreafrancia
Una volta facevo
refactor senza test…

82.
@andreafrancia
Refactor e test lenti

83.
@andreafrancia
Architettura
esagonale

84.
@andreafrancia
Anche i test chiedono
il refactor

85.
@andreafrancia
Quando fare refactor?

86.
@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.”

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

88.
@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)

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

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

91.
@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

92.
@andreafrancia
Test-First

93.
@andreafrancia
Test-First ≠ TDD

94.
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.

95.
@andreafrancia
Test-Driven
Development

96.
@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)

97.
@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

98.
@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

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

100.
@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.

101.
@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
…

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

103.
When refactor?

104.
Test lenti e test veloci

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

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

107.
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

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

109.
• fast
• reliable
• slow
• fragile

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

111.
@andreafrancia
Continuous
Integration

112.
@andreafrancia
Continuous
Integration ≠ Jenkins

113.
@andreafrancia
Continuous
Integration ≠ Git Flow

114.
@andreafrancia
Continuous Integration
≠ merge da master

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

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

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

118.
@andreafrancia
Integrazione continua
applicata alle dipendenze

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

120.
Il rosso giusto

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