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

@andreafrancia
Chi sono

Sono un programmatore da
tanto tempo

@andreafrancia
Faccio cose

Trovo comodo usare i test
automatici per lavorare

Occasionalmente faccio il
coach (di TDD)

Conduco il TDD Milano

Ho un progetto open source

Ho cambiato un sacco di
aziende

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

@andreafrancia
Ma poi …

@andreafrancia
Test >
Documentazione

@andreafrancia

@andreafrancia
Cos’è XP?

@andreafrancia

@andreafrancia
Quanti ce ne restano?
Survived ?
Survived !

@andreafrancia
Scrum

@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

@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

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

@andreafrancia
Scrum + Technical
practices ≈ XP

@andreafrancia
Scrum - Technical
practices = ?

@andreafrancia

@andreafrancia
Come vanno le cose
in un progetto XP?

@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

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

@andreafrancia
Quali sono le pratiche
ingegneristiche?

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

@andreafrancia
~50
Quante sono le 12 pratiche XP?

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

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

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

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

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

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

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

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

@andreafrancia
La mia esperienza
con le pratiche

@andreafrancia
Pair Programming

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

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

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

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

@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

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

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

@andreafrancia
Coding Standards

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

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

@andreafrancia

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

@andreafrancia
Non è necessario
scrivere un documento!

@andreafrancia
Tradizione orale +
“buon” esempio

@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

@andreafrancia

@andreafrancia
Testing automatico

@andreafrancia
Pratica utile
indipendentemente da
XP

@andreafrancia
È l’alternativa al
debugging disperato

@andreafrancia
È indispensabile per il
refactor

@andreafrancia
“non puoi sempre
metterci un taccone”

@andreafrancia
“hai cambiato un
codice che funzionava!”

@andreafrancia
“se non è rotto non
aggiustarlo!”

@andreafrancia
I framework xUnit ci sono
per qualsiasi linguaggio

@andreafrancia

Se non ci sono si creano

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

@andreafrancia
Da dove iniziare?

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

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

@andreafrancia
Non chiedete al
management di poter
testare

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

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

@andreafrancia
Design incrementale

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

@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

@andreafrancia
Usare il simple design
per valutare un refactor

@andreafrancia
Se un refactor non
migliora il design si butta

@andreafrancia
Refactor

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

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

@andreafrancia
Una volta facevo
refactor senza test…

@andreafrancia
Refactor e test lenti

@andreafrancia
Architettura
esagonale

@andreafrancia
Anche i test chiedono
il refactor

@andreafrancia
Quando fare refactor?

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

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

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

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

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

@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

@andreafrancia
Test-First

@andreafrancia
Test-First ≠ TDD

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.

@andreafrancia
Test-Driven
Development

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

@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

@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

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

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

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

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

When refactor?

Test lenti e test veloci

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

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

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

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

• fast
• reliable
• slow
• fragile

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

@andreafrancia
Continuous
Integration

@andreafrancia
Continuous
Integration ≠ Jenkins

@andreafrancia
Continuous
Integration ≠ Git Flow

@andreafrancia
Continuous Integration
≠ merge da master

@andreafrancia
Cosa vuol dire integrare
due linee di sviluppo?

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

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

@andreafrancia
Integrazione continua
applicata alle dipendenze

@andreafrancia
Daily deployment
(una specie di
integrazione continua)

Il rosso giusto

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