refactoring smell code
Post on 02-Jul-2015
91 Views
Preview:
DESCRIPTION
TRANSCRIPT
SCAI S.p.A. 1Project & Delivery Area
Refactoring e Code Smellsdi
Alessandro Graps
Bologna, 22/11/2013
SCAI S.p.A. 2
Indice
TeoricoIntroduzioneIngegneria del softwareRefactoringCode SmellCasi d’usoConclusioni
WorkshopProva finale
Project & Delivery Area
SCAI S.p.A. 3Project & Delivery Area
Ingegneria del Software
Cos’e’
L’Ingegneria del Sw (Software Engineering) è una disciplina metodologica,cioè studia i metodi di produzione, le teorie alla base dei metodi, e gli strumenti di sviluppo e misura della qualità dei sistemi software.
SCAI S.p.A. 4Project & Delivery Area
Ingegneria del Software
Cos’e’
L’Ingegneria del Sw (Software Engineering) è una disciplina metodologica,cioè studia i metodi di produzione, le teorie alla base dei metodi, e gli strumenti di sviluppo e misura della qualità dei sistemi software.
È anche una disciplina empirica, cioè basata sull’esperienza e sulla storia dei progetti passati.
SCAI S.p.A. 5Project & Delivery Area
Ingegneria del Software
La produttività dell’industria sw è bassa
Da un’analisi di 13.522 progetti di costruzione sw: (Standish Report 2003)
66% di tutti i progetti falliscono (non hanno risultato utile).
82% dei progetti superano i tempi previsti.
48% dei progetti producono sistemi senza le funzioni richieste dai clienti.
55 miliardi $ di spreco considerando solo i progetti USA.
SCAI S.p.A. 6Project & Delivery Area
Ingegneria del Software
SCAI S.p.A. 7Project & Delivery Area
Perche’ falliscono i progetti sw: I rischi
Quali sono i rischi principali di chi sviluppa software?
SCAI S.p.A. 8Project & Delivery Area
Perche’ falliscono i progetti sw: I rischi
Quali sono i rischi principali di chi sviluppa software?
Turnover dello staff.
SCAI S.p.A. 9Project & Delivery Area
Perche’ falliscono i progetti sw: I rischi
Quali sono i rischi principali di chi sviluppa software?
Turnover dello staff.
Realizzare funzioni non richieste.
SCAI S.p.A. 10Project & Delivery Area
Perche’ falliscono i progetti sw: I rischi
Quali sono i rischi principali di chi sviluppa software?
Turnover dello staff.
Realizzare funzioni non richieste.
Ritardi nella consegna.
SCAI S.p.A. 11Project & Delivery Area
Perche’ falliscono i progetti sw: I rischi
Quali sono i rischi principali di chi sviluppa software?
Turnover dello staff.
Realizzare funzioni non richieste.
Ritardi nella consegna.
Superare il budget di progetto.
SCAI S.p.A. 12Project & Delivery Area
Perche’ falliscono i progetti sw: I rischi
Quali sono i rischi principali di chi sviluppa software?
Turnover dello staff.
Realizzare funzioni non richieste.
Ritardi nella consegna.
Superare il budget di progetto.
Realizzare un sistema inusabile.
SCAI S.p.A. 13Project & Delivery Area
Perche’ falliscono i progetti sw: I rischi
Quali sono i rischi principali di chi sviluppa software?
Turnover dello staff.
Realizzare funzioni non richieste.
Ritardi nella consegna.
Superare il budget di progetto.
Realizzare un sistema inusabile.
Realizzare un sistema incapace di funzionare insieme con altri sistemi esistenti.
SCAI S.p.A. 14Project & Delivery Area
In che contesto
Nello scorso workshop abbiamo parlato di metodologie di sviluppo.
SCAI S.p.A. 15Project & Delivery Area
In che contesto
Nello scorso workshop abbiamo parlato di metodologie di sviluppo.
L'obiettivo generale dell’ ingegneria del software è quello di creare software di alta qualità in modo efficiente.
SCAI S.p.A. 16Project & Delivery Area
In che contesto
Nello scorso workshop abbiamo parlato di metodologie di sviluppo.
L'obiettivo generale dell’ ingegneria del software è quello di creare software di alta qualità in modo efficiente.
Perche’ non lo faccio? Ci sono sempre pressioni e ragioni per scrivere software di basso livello.
SCAI S.p.A. 17Project & Delivery Area
Perche’ scriviamo codice non efficiente e di bassa qualita’?
SCAI S.p.A. 18Project & Delivery Area
Perche’ scriviamo codice non efficiente e di bassa qualita’?
I requisiti che cambiano nel tempo rendono difficile l’aggiornamento del codice.
SCAI S.p.A. 19Project & Delivery Area
Perche’ scriviamo codice non efficiente e di bassa qualita’?
I requisiti che cambiano nel tempo rendono difficile l’aggiornamento del codice.
Tempo e denaro possono ci possono fare scrivere codice di bassa qualita’.
SCAI S.p.A. 20Project & Delivery Area
Perche’ scriviamo codice non efficiente e di bassa qualita’?
I requisiti che cambiano nel tempo rendono difficile l’aggiornamento del codice.
Tempo e denaro possono ci possono fare scrivere codice di bassa qualita’.
Impariamo un modo migliore.
SCAI S.p.A. 21Project & Delivery Area
Due domande
Come possiamo fixare il codice?1
SCAI S.p.A. 22Project & Delivery Area
Due domande
Come possiamo sapere se il
Nostro codice e’ scritto male..
Se l’applicazione funziona bene?
2
SCAI S.p.A. 23Project & Delivery Area
Refactoring
SCAI S.p.A. 24Project & Delivery Area
Refactoring
Definizione: Il refactoring e’ la modificha del codice per migliorare la leggibilità, la manutenibilita’ e la sua estendibilita’ senza cambiare il suo reale funzionamento.
SCAI S.p.A. 25Project & Delivery Area
Refactoring
Definizione: Il refactoring e’ la modificha del codice per migliorare la leggibilità, la manutenibilita’ e la sua estendibilita’ senza cambiare il suo reale funzionamento.
Comportamento esterno non cambia.
SCAI S.p.A. 26Project & Delivery Area
Refactoring
Definizione: Il refactoring e’ la modificha del codice per migliorare la leggibilità, la manutenibilita’ e la sua estendibilita’ senza cambiare il suo reale funzionamento.
Comportamento esterno non cambia.
La struttura interna e’ migliorata.
SCAI S.p.A. 27Project & Delivery Area
Refactoring
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
SCAI S.p.A. 28Project & Delivery Area
Refactoring:Un semplice esempio
Move a method:
Motivazione: Un metodo e’ utilizzato o sara’ utilizzato da altre classi che la classe in cui e’ definito.
SCAI S.p.A. 29Project & Delivery Area
Refactoring:Un semplice esempio
Move a method:
Motivazione: Un metodo e’ utilizzato o sara’ utilizzato da altre classi che la classe in cui e’ definito.
Tecnica: Creare un nuovo metodo con le stesse firme nella classe comune. Si elimina la chiamata al vecchio metodo e si rimuove del tutto il metodo.
SCAI S.p.A. 30Project & Delivery Area
Refactoring:Un semplice esempio
SCAI S.p.A. 31Project & Delivery Area
Refactoring:Pericolo!
SCAI S.p.A. 32Project & Delivery Area
Refactoring:Pericolo!
Refactoring può introdurre ulteriori problemi, perché ogni volta che si modifica il software si può introdurre un bug!
SCAI S.p.A. 33Project & Delivery Area
Refactoring:Pericolo!
Refactoring può introdurre ulteriori problemi, perché ogni volta che si modifica il software si può introdurre un bug!
Prima di farlo:
SCAI S.p.A. 34Project & Delivery Area
Refactoring:Pericolo!
Refactoring può introdurre ulteriori problemi, perché ogni volta che si modifica il software si può introdurre un bug!
Prima di farlo:
Il refactoring aggiunge rischio!
SCAI S.p.A. 35Project & Delivery Area
Refactoring:Pericolo!
Refactoring può introdurre ulteriori problemi, perché ogni volta che si modifica il software si può introdurre un bug!
Prima di farlo:
Il refactoring aggiunge rischio!
E 'costoso - stiamo spendendo tempo in fase di sviluppo, ma non "vediamo" nessuna differenze esterne?
SCAI S.p.A. 36Project & Delivery Area
Refactoring:Pericolo!
Refactoring può introdurre ulteriori problemi, perché ogni volta che si modifica il software si può introdurre un bug!
Prima di farlo:
Il refactoring aggiunge rischio!
E 'costoso - stiamo spendendo tempo in fase di sviluppo, ma non "vediamo" nessuna differenze esterne?
Possiamo ripetere i test?
SCAI S.p.A. 37Project & Delivery Area
Refactoring:Pericolo!
Refactoring può introdurre ulteriori problemi, perché ogni volta che si modifica il software si può introdurre un bug!
Prima di farlo:
Il refactoring aggiunge rischio!
E 'costoso - stiamo spendendo tempo in fase di sviluppo, ma non "vediamo" nessuna differenze esterne?
Possiamo ripetere i test?
Perché stiamo facendo questo?
SCAI S.p.A. 38Project & Delivery Area
Refactoring:Motivazioni
Scrivere codice corretto la prima volta e’ difficile, dal refactoring otteniamo i seguentibenefici:
Riduzione delle dimensioni del codice.
SCAI S.p.A. 39Project & Delivery Area
Refactoring:Motivazioni
Scrivere codice corretto la prima volta e’ difficile, dal refactoring otteniamo i seguentibenefici:
Riduzione delle dimensioni del codice.
Semplificazione del codice.
SCAI S.p.A. 40Project & Delivery Area
Refactoring:Motivazioni
Scrivere codice corretto la prima volta e’ difficile, dal refactoring otteniamo i seguentibenefici:
Riduzione delle dimensioni del codice.
Semplificazione del codice.
Miglioramento notevole della mantenibilita’: E’ imporante in un mondo dove i requisiti cambiano spesso.
SCAI S.p.A. 41Project & Delivery Area
Refactoring:Quali problemi risolve?
Per correggere un bug ci vuole troppo tempo!
SCAI S.p.A. 42Project & Delivery Area
Refactoring:Quali problemi risolve?
Per correggere un bug ci vuole troppo tempo!
Aggiungere una nuova funzionalità è... un’impresa difficile e rischiosa!!!
SCAI S.p.A. 43Project & Delivery Area
Refactoring:Quali problemi risolve?
Per correggere un bug ci vuole troppo tempo!
Aggiungere una nuova funzionalità è... un’impresa difficile e rischiosa!!!
E’ diventato impossibile stimare tempi e costi degli interventi richiesti dal cliente???
SCAI S.p.A. 44Project & Delivery Area
Refactoring:Quali problemi risolve?
Per correggere un bug ci vuole troppo tempo!
Aggiungere una nuova funzionalità è... un’impresa difficile e rischiosa!!!
E’ 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.
SCAI S.p.A. 45Project & Delivery Area
Refactoring:Esempio codice
Introduzione di un Null Object
Motivazione: Ci sono molti controlli per i null object
Tecnica: Gestiamo il valore null nel nostro codice.
SCAI S.p.A. 46Project & Delivery Area
Refactoring:Esempio codice
Customer c = findCustomer(...); ...
if (customer == null) { name = “occupant”
} else { name = customer.getName()
} if (customer == null) { …
SCAI S.p.A. 47Project & Delivery Area
Refactoring:Esempio codice
public class NullCustomer extends Customer {public String getName() {return “occupant”
}---------------------------------------------------------Customer c = findCustomer()name = c.getName()
SCAI S.p.A. 48Project & Delivery Area
Refactoring:Esempio codice
Abbiamo completamente eliminato l'istruzione if, sostituendo i controlli per nullcon un oggetto nullo che gestisce i valori "NULL".
SCAI S.p.A. 49Project & Delivery Area
Refactoring:Altro esempio
Sostituzione delle condizioni con il polimorfismo
Motivazione: Abbiamo nel nostro codice una serie di condizioni che gestiscono un comportamento diverso a seconda del tipo dell’oggetto.
Tecnica: Ogni condizione verra’ gestita con l’ovveride di una sottoclasse astraendo il metodo originale.
SCAI S.p.A. 50Project & Delivery Area
Refactoring:Altro esempio
double getSpeed() { switch (_type) {
case EUROPEAN: return getBaseSpeed();
case AFRICAN: return getBaseSpeed() - getLoadFactor() *
_numberOfCoconuts; case NORWEGIAN_BLUE:
return (_isNailed) ? 0 : getBaseSpeed(_voltage); } throw new RuntimeException ("Should be unreachable"); }
SCAI S.p.A. 51Project & Delivery Area
Refactoring:Altro esempio
SCAI S.p.A. 52Project & Delivery Area
Refactoring:Quando lo faccio?
Quando si aggiunge una nuova funzionalita’:
SCAI S.p.A. 53Project & Delivery Area
Refactoring:Quando lo faccio?
Quando si aggiunge una nuova funzionalita’:
Prima di aggiungere una nuova funzionalita’, bisogna assicurarsi che il codice attuale sia pulito. Quando ci aiutera’ a scrivere la nuova funzionalita’ in maniera piu’ snella.
SCAI S.p.A. 54Project & Delivery Area
Refactoring:Quando lo faccio?
Quando si aggiunge una nuova funzionalita’:
Prima di aggiungere una nuova funzionalita’, bisogna assicurarsi che il codice attuale sia pulito. Quando ci aiutera’ a scrivere la nuova funzionalita’ in maniera piu’ snella.
Quando devo correggere bugs.
SCAI S.p.A. 55Project & Delivery Area
Refactoring:Quando lo faccio?
Quando si aggiunge una nuova funzionalita’:
Prima di aggiungere una nuova funzionalita’, bisogna assicurarsi che il codice attuale sia pulito. Quando ci aiutera’ a scrivere la nuova funzionalita’ in maniera piu’ snella.
Quando devo correggere bugs.
Quando si esegue una code review.
SCAI S.p.A. 56Project & Delivery Area
Refactoring:Come identifico codice da rifattorizzare?
Martin Fowler usa “Code smells” per identificare quando rifattorizzare.
SCAI S.p.A. 57Project & Delivery Area
Refactoring:Come identifico codice da rifattorizzare?
Martin Fowler usa “Code smells” per identificare quando rifattorizzare.
Code Smell sono parti cattive nel codice, un po’ come i pattern difettosi nel codice.
SCAI S.p.A. 58Project & Delivery Area
Refactoring:Come identifico codice da rifattorizzare?
Martin Fowler usa “Code smells” per identificare quando rifattorizzare.
Code Smell sono parti cattive nel codice, un po’ come i pattern difettosi nel codice.
Molte persone legano il code smell per specificare una rifattorizzazione per fixare lo smell.
SCAI S.p.A. 59Project & Delivery Area
Code Smell
SCAI S.p.A. 60Project & Delivery Area
Code Smell:Codice duplicato
Male perche’ rischiamo di introdurre un bug se modifichiamo una sola istanza del codice dimenticando le altre.
Cerchiamo di creare un unico metodo in un punto comune al progetto.
SCAI S.p.A. 61Project & Delivery Area
Code Smell:Metodi lunghi
Sono difficili da capire.
Problemi di prestazioni.
Frammentiamo
SCAI S.p.A. 62Project & Delivery Area
Code Smell:Classi larghe
Le classi cercano di fare tutto e troppo.
Dividiamo in piu’ classi
SCAI S.p.A. 63Project & Delivery Area
Code Smell:Liste parametri troppo lunghe
Difficili da capire. Possono essereinconsistenti.
Utilizzare oggetti per lo scambio diparametri.
SCAI S.p.A. 64Project & Delivery Area
Code Smell:Cambi di divergenze
Relativi alla coesione: sintomi: un cambiamento richiede la modifica di diversi metodi; un altro cambiamento richiede la modifica di un altro sottoinsieme.
Non esiste un singolo punto dove operare per eseguire una modifica
SCAI S.p.A. 65Project & Delivery Area
Code Smell:Eccessivo uso delle primitive
Sfruttare gli oggetti
SCAI S.p.A. 66Project & Delivery Area
Code Smell:Modifiche a cascata
Una modifica ne provoca molte altre a cascata
Regressione
SCAI S.p.A. 67Project & Delivery Area
Code Smell:Campi temporanei
Difficili da gestire
SCAI S.p.A. 68Project & Delivery Area
Code Smell:Data Class
Adatte solo nei primi stati di progettazione.
SCAI S.p.A. 69Project & Delivery Area
Code Smell:Ambiente errato
Spostare il metodo nella classe corretta
SCAI S.p.A. 70Project & Delivery Area
Code Smell:Commenti
I commenti sono a volte utilizzati per nascondere cattivo codice.
Sono spesso utilizzati come deodorante.
SCAI S.p.A. 71Project & Delivery Area
Code Smell:Commenti
/**Restituisce l’area di un rettangolo*param w larghezza del rettangolo*param h altezza del rettangolo*return area del rettangolo*/public float GetA(float w, float h) {
//Calcolo area float res = w*h;//Restituzione risultatoreturn res;
}
public float GetArea(float width, float height) {return width * height;}
SCAI S.p.A. 72Project & Delivery Area
Code Smell:Altro
Many more smells at:
http://c2.com/cgi/wiki?CodeSmell
Come ripulire il codice
http://wiki.java.net/bin/view/People/SmellsToRefactorings
SCAI S.p.A. 73Project & Delivery Area
Perche’ lo facciamo?
Code Smell e Refactoring sono tecniche per aiutarci a scoprire i problemi nella progettazione e realizzazione di software e di applicare soluzioni note per non rincorrere in questi problemi.
Dovrebbero essere utilizzati per tutto il tempo? Si deve pensare sempre a loro, ma si applicano solo quando hanno un senso. A volte e’ necessario un «metodo lungo…»
Ma pensate sempre se questa e’ la soluzione migliore.
SCAI S.p.A. 74Project & Delivery Area
Perche’ lo facciamo?
Ricordate sempre che queste modifiche possono introdurre bugs nel codice.
Riduciamo il rischio.
È necessario verificare costantemente -con test automatizzati ove possibile.
Utilizzare i modelli di refactoring – ne ho mostrati due ... ma ne esistono di più .. molti di più!
http://www.refactoring.com/catalog/index.html
Utilizzare strumenti per velocizzare.
SCAI S.p.A. 75Project & Delivery Area
Rispondiamo al capo!
"Il refactoring è un'attività in prioritaria - Sono pagato per scrivere nuove funzioni e sistemare quelle esistenti."
SCAI S.p.A. 76Project & Delivery Area
Ricordiamoci
Strumenti/tecnologie sono ora disponibili per consentire il refactoring in modo rapido e relativamente indolore.
Esperienze riportate da alcuni programmatori object-orientedsuggeriscono che il sovraccarico di refactoring è più che compensato da sforzi ridotti e intervalli in altre fasi di sviluppo del programma.
SCAI S.p.A. 77Project & Delivery Area
Conclusioni
Il Refactoring migliora la progettazione di software.
SCAI S.p.A. 78Project & Delivery Area
Conclusioni
Il Refactoring crea software facile da capire
La struttura e’ migliorata, il codice duplicato viene eliminato, etc.
SCAI S.p.A. 79Project & Delivery Area
Conclusioni
Il Refactoring aiuta a scovare i bugs
Il refactoring aiuta a comprendere il codice e questo aiuta lo sviluppatore a trovare I bug e anticipando potenziali bug.
SCAI S.p.A. 80Project & Delivery Area
Conclusioni
Il Refactoring aiuta a programmare velocemente
Perche’ un buon design permette di compiere progressi veloci.
SCAI S.p.A. 81Project & Delivery Area
Riferimenti
http://www.irregularwebcomic.net/cgi-bin/comic.pl?comic=687
http://www.refactoring.com/catalog/index.html
http://www.cs.colorado.edu/~kena/classes/6448/s05/lectures/lecture18.pdf
http://www.codeproject.com/KB/architecture/practicalexp.aspx
SCAI S.p.A. 82Project & Delivery Area
Workshop
SCAI S.p.A. 83Project & Delivery Area
Prova
top related