La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

1 RE F ACTORING APPLIED: Pratica avanzata del Refactoring www.luca.minudel.it.

Presentazioni simili


Presentazione sul tema: "1 RE F ACTORING APPLIED: Pratica avanzata del Refactoring www.luca.minudel.it."— Transcript della presentazione:

1 1 RE F ACTORING APPLIED: Pratica avanzata del Refactoring

2 2 Sponsor

3 3 Obiettivi Refactoring, perché? Quali prerequisiti per il Refactoring? Come comprendere e reagire ai feedback del codice? Refactoring, perché? Quali prerequisiti per il Refactoring? Come comprendere e reagire ai feedback del codice?

4 4 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 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

5 5 Premessa Introduzione al Refactoring: Introduzione al Refactoring:

6 6 RE F ACTORING, PERCHÉ? Riconoscere situazioni e problemi che si risolvono con il Refactoring Riconoscere situazioni e problemi che si risolvono con il Refactoring

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

8 8 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 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

9 9 Quando e quanto Refactoring (Disegno) fare? Per dominare la complessità il sistema da realizzare ci sembra molto complesso Per permettere levoluzione 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? Per dominare la complessità il sistema da realizzare ci sembra molto complesso Per permettere levoluzione 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?

10 10 Refactoring Vs Design disegno up-front e refactoring possono coesistere i principi del disegno valgono ancora ed è necessario conoscerli disegno up-front e refactoring possono coesistere i principi del disegno valgono ancora ed è necessario conoscerli

11 11 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 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

12 12 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 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 -> Migliorare grazie ai feedback del codice

13 13 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 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

14 14 Cosè buon Refactoring? Il codice diventa più semplice... da capire da analizzare da modificare da testare Il codice diventa più semplice... da capire da analizzare da modificare da testare

15 15 Cosè buon Refactoring? È secondario mah… anche per lutente potrebbero esserci benefici :-D Estrema semplicità -> meno errori sui dati meno errori run-time (o fermi macchina) programmi più veloci niente spreco di risorse Estrema semplicità -> meno errori sui dati meno errori run-time (o fermi macchina) programmi più veloci niente spreco di risorse

16 16 Refactoring (Design): Quali problemi risolve? i clienti continuano a chiedere modifiche, il programma è a fine corsa, nessuno ha il coraggio di rifarlo. è diventato impossibile stimare tempi e costi degli interventi richiesti dal cliente??? aggiungere una nuova funzionalità è... unimpresa difficile e rischiosa!!! per correggere un bug ci vuole troppo tempo!

17 17 Azioni concrete:

18 18 RE F ACTORING QUALI PREREQUISITI? Dotarsi del necessario per applicare il Refactoring in continuo miglioramento Dotarsi del necessario per applicare il Refactoring in continuo miglioramento

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

20 20 Refactoring del 1° tipo, VS.NET & Vil Command: C:\Programmi\...\refactoringmetrics.cmd Arguments: $(TargetDir)*$(TargetExt) $(SolutionDir) 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 ^ ^ ^ > _s.tmp copy _locmembri.tmp+_s.tmp oometrics4refactoring.html > nul oometrics4refactoring.html

21 21 Refactoring del 1° tipo & TDD

22 22 Refactoring del 2° tipo Le code smell che richiedono naso codice duplicato cambiamenti divergenti shotgun surgery feature envy generalizzazione speculativa commenti Le code smell che richiedono naso codice duplicato cambiamenti divergenti shotgun surgery feature envy generalizzazione speculativa commenti

23 23 Refactoring del 2° tipo: fare pratica!

24 24 Refactoring del 2° tipo: la preparazione Programmazione OO DisegnoArchitettura DisegnoArchitettura

25 25 Refactoring del 2° tipo: la preparazione 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 servono? 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 servono? Programmazione OO

26 26 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)? Che diagrammi di modellazione si usano per descrivere un Disegno (UML)? 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)? Che diagrammi di modellazione si usano per descrivere un Disegno (UML)?

27 27 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, abstract- layered) e controllo (Centralizzed call-return manager; event-driven broadcast, interrupt driven) di una 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, abstract- layered) e controllo (Centralizzed call-return manager; event-driven broadcast, interrupt driven) di una architettura?

28 28 Refactoring e Design Pattern? Refactoring to Patterns di Joshua Kerievsky Addison Wesley Professional applicare i Pattern per migliorare del codice già scritto (con il refactoring) dà ottimi risultati… …migliori che applicare i Pattern nel disegno iniziale Refactoring to Patterns di Joshua Kerievsky Addison Wesley Professional applicare i Pattern per migliorare del codice già scritto (con il refactoring) dà ottimi risultati… …migliori che applicare i Pattern nel disegno iniziale

29 29 Azioni concrete:

30 30 COMPRENDERE & REAGIRE AI FEED B ACK DEL CODICE Esempio "Live" di Refactoring del 2° tipo applicato al codice dell'interazione utente Esempio "Live" di Refactoring del 2° tipo applicato al codice dell'interazione utente !

31 31 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 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

32 32 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 allesempio il controllo della navigazione: FormarsiRefactoring Programmazione e disegno OO 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 allesempio il controllo della navigazione: FormarsiRefactoring Programmazione e disegno OO

33 33 Prossime letture! voce Object Oriented Design voce Object Oriented Design

34 34 Domande Risposte &

35 35 Fine


Scaricare ppt "1 RE F ACTORING APPLIED: Pratica avanzata del Refactoring www.luca.minudel.it."

Presentazioni simili


Annunci Google