REFACTORING
APPLIED:
Pratica avanzata del Refactoring
www.luca.minudel.it
1
Sponsor
2
Obiettivi
Refactoring, perché?
Quali prerequisiti per il Refactoring?
Come comprendere e reagire ai feedback
del codice?
3
Premessa
Refactoring è il processo per modificare
un sistema software in modo tale da
migliorare la struttura interna del codice
senza alterarne il comportamento esterno.
M. Fowler
4
Premessa
Introduzione al Refactoring:
http://www.agileday.it/slides/BrunoBossola.zip
5
REFACTORING, PERCHÉ?
Riconoscere situazioni e problemi che si
risolvono con il Refactoring
6
Il Refactoring è Disegno
Il Disegno classico... non si fa o... si fa con un
processo diviso in “Fasi”
Il Refactoring si fa continuamente: mentre si
scrive il codice
7
Il Refactoring è Disegno
Il Disegno classico up-front:
raccolta dei Requisiti e definizione Specifiche
il Disegno “up-front”
e poi Implementazione (in fretta: c’è poco tempo)
Il Refactoring continuo:
TDD: Rosso->Verde->Refactoring
Implementa->problemi dal codice?->Refactoring
8
Quando e quanto Refactoring
(Disegno) fare?
Per dominare la complessità
il sistema da realizzare ci sembra molto complesso
Per permettere l’evoluzione
il cliente desidera poter aggiungere o modificare
funzionalità senza rifare tutto
la software house vuole ridurre i costi di manutenzione o
adattare il sistema a più clienti
Quanto?
9
Refactoring Vs Design
disegno up-front e refactoring possono
coesistere
i principi del disegno valgono ancora ed è
necessario conoscerli
10
Refactoring Vs Design
Quali i vantaggi del Refactoring?
ci sono requisiti importanti che il cliente scopre
dopo...
ci sono cose a cui il team di sviluppo non
aveva pensato!
quando il progetto è lungo i bisogni del cliente
possono cambiare... e con loro i requisiti
-> Adattarsi velocemente ai cambiamenti
11
Refactoring Vs Design
Quali i vantaggi del Refactoring?
è difficile “indovinare” il disegno migliore al primo colpo
non si riesce a decidere come implementare alcune
funzionalità
implementando una funzionalità il disegno… degenera
a volte ci sono pezzi di codice che... non si sa più cosa
fanno o come funzionano
altre volte si può migliorare il disegno... cancellando parti
di codice
12
-> Migliorare grazie ai feedback del codice
Cos’è
buon Refactoring (Design) ?
Il codice diventa più
Flessibile
riesco a fare una modifica intervenendo localmente in
parti isolate del codice
Robusto
faccio una singola modifica del codice e questa incide
solo sul codice strettamente/logicamente correlato
Riusabile
riesco facilmente ad estrarre dal codice le funzionalità
per riutilizzarle
13
Cos’è
buon Refactoring?
Il codice diventa più semplice ...
da capire
da analizzare
da modificare
da testare
14
Cos’è
buon Refactoring?
È secondario mah… anche per l’utente
potrebbero esserci benefici :-D
Estrema semplicità ->
meno errori sui dati
meno errori run-time (o fermi macchina)
programmi più veloci
niente spreco di risorse
15
Refactoring (Design):
Quali problemi risolve?
per correggere un bug ci vuole troppo
tempo!
aggiungere una nuova funzionalità è...
un’impresa difficile e rischiosa!!!
è diventato impossibile stimare tempi e
costi degli interventi richiesti dal cliente???
i clienti continuano a chiedere modifiche,
il programma è a “fine corsa”, nessuno ha
il coraggio di rifarlo.
16
Azioni concrete:
17
REFACTORING
QUALI PREREQUISITI?
Dotarsi del necessario per applicare il Refactoring
in continuo miglioramento
18
Refactoring del 1° tipo
Le “code smell” che possono essere
individuate automaticamente con le
metriche OO
metodi/classi lunghe
lunghe liste di parametri
liste di switch/if
generalizzazione speculativa
!
vedi oometrics4refactoring.html
19
Refactoring del 1° tipo,
VS.NET & Vil
Command:
C:\Programmi\...\refactoringmetrics.cmd
Arguments:
$(TargetDir)*$(TargetExt) $(SolutionDir)
vil /nologo /a=%1 /m=loc,locals /s=loc
... /sc=imp /h
... /title="Membri troppo lunghi"
... /outhtmlshort=%2_locmembri.tmp
vil ...
cd /d %2
echo ^<br^> ^<br^> ^<br^> > _s.tmp
copy _locmembri.tmp+_s.tmp+...
... oometrics4refactoring.html > nul
20
oometrics4refactoring.html
Refactoring del 1° tipo & TDD
21
Refactoring del 2° tipo
Le “code smell” che richiedono “naso”
codice duplicato
cambiamenti divergenti
shotgun surgery
feature envy
generalizzazione speculativa
commenti
22
Refactoring del 2° tipo:
fare pratica!
23
Refactoring del 2° tipo:
la preparazione
Programmazione OO
Disegno
Architettura
24
Refactoring del 2° tipo:
la preparazione
Programmazione OO
Cos'è il paradigma di programmazione OO? (cosa lo distingue dal
paradigma di progr. procedurale, di progr. modulare/data hiding, di
astrazione dei dati)
Quando definire una classe base o quando definire un'interfaccia?
Quando usare l'ereditarietà e quando il contenimento (riferimento,
puntatore)?
Quando usare l'ereditarietà e quando usare un “flag” per discriminare
diversi tipi?
Quando usare il polimorfismo run-time (funzioni virtuali) e quando il
polimorfismo compile-time (template/generics)?
Le funzioni (namespace, classi, costruttori, operatori, conversioni,
overloading, funzioni virtuali, membri statici, visibilità, eccezioni,
const/readonly...) del linguaggio che astrazioni definiscono e a cosa 25
servono?
Refactoring del 2° tipo:
la preparazione
Disegno
Cos'è il disegno e che differenza c'è con l'analisi?
Quando serve fare disegno?
Come si usano le schede CRC?
Secondo quali criteri un disegno è buono (rigidità, fragilità, immobilità; alta
coesione-basso accoppiamento)?
Quali sono i casi di buon disegno da prendere come esempio o da
conoscere?
- I Design Pattern
- ISO OSI Reference Model, TCP/IP Reference Model
- Protocollo HTTP
- Stili, paradigmi e principi dell'interazione utente (HCI)
Quali principi guidano il Design (LSP Liskov Substitution Principle, OCP
Open Close Principle, DIP Dependency Inversion Principle, SRP Single
Responsibility Principle, ISP Interface Segregation Principle,
REP/CCP/CRP/ADP/SDP/SAP Packaging Principles, The Martin Metrics)? 26
Che diagrammi di modellazione si usano per descrivere un Disegno (UML)?
Refactoring del 2° tipo:
la preparazione
Architettura
Cos'è l'architettura e cosa la distingue dal disegno?
Cos'è l'architettura e cosa la distingue dall'infrastruttura?
Da quali requisiti dipende e che obiettivi ha l'architettura di un sistema?
Quali sono i principali Enterprise Application Patterns (multi-tiers, ...)?
Quali sono i principali modelli di strutturazione (repository, C/S, abstractlayered) e controllo (Centralizzed call-return manager; event-driven
broadcast, interrupt driven) di una architettura?
27
Refactoring e Design Pattern?
Refactoring to Patterns
di Joshua Kerievsky
Addison Wesley Professional
http://industriallogic.com/xp/refactoring
applicare i Pattern per migliorare del
codice già scritto (con il refactoring)
dà ottimi risultati…
…migliori che applicare i Pattern nel
disegno iniziale
28
Azioni concrete:
29
COMPRENDERE & REAGIRE
AI FEEDBACK DEL CODICE
Esempio "Live" di Refactoring del 2° tipo
applicato al codice dell'interazione utente
!
30
Concludendo: i 3 punti chiave
Individuare i casi in cui applicare il
Refactoring da maggiore beneficio (ROI)
Riconoscere nel codice i difetti che il
Refactoring risolve e i benefici che comporta
Applicare il Refactoring con continuità e
formarsi sul design OO
31
Call to Action!
Fare pratica
al lavoro: selezionare i progetti con maggiore
ROI per il Refactoring (feedback Vil e Svi/PM)
su progetti propri/open-source
per esercizio: aggiungere all’esempio il
controllo della navigazione:
http://www.ugidotnet.org/articles/articles_read.aspx?ID=90
Formarsi
Refactoring
Programmazione e disegno OO
32
Prossime letture!
http://www.refactoring.com/
http://c2.com/cgi/wiki?CodeSmell
http://wiki.java.net/bin/view/People/SmellsToRefactorings
http://industriallogic.com/xp/refactoring
http://www.sei.cmu.edu/str/descriptions/oodesign.html
http://www.objectmentor.com/resources/ voce “Object Oriented Design”
www.martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
http://martinfowler.com/books.html#eaa
http://www.extremeprogramming.org/
http://www.uml.org/
http://msdn.microsoft.com/msdnmag/issues/04/04/ExtremeProgramming/
http://www.microsoft.com/learning/books/professional/
33
Domande
Risposte
&
34
Fine
35