Abstract
- Perché fare Refactoring?
Riconoscere le situazioni ed i problemi che si risolvono con il Refactoring
- Quali i prerequisiti per fare Refactoring?
Dotarsi del necessario per applicare il Refactoring in continuo miglioramento
- Come comprendere e reagire ai feedback del codice?
Esempio "Live" di Refactoring del 2° tipo applicato al codice dell'interazione utente
1 - quando e quanto
2 - gli strumenti per (non i tool)
3 - esempio “live” di refactoring
Il punto da cui partiamo è questa defininizione.
No intro
tutte le informazioni utili per applicare il Refactoring anche in un ambiente Ostile (molte di queste nuove metodologie si applicano meglio in team)
- non si fa xKè la SH non compra i Tool (ora c’è Together CE) o non fa formazione e quindi il Disegno lo sa leggere solo chi l’ha scritto e non a chi serve
-Nel disegno classico lo fa il progettista
-Nel Refactoring lo fa lo Sviluppatore
Analisi:
- Cosa il sistema deve fare (il comportamento esterno)- Usa il linguaggio dell’Utente (Non qui si parla di .NET/Java, Remoting/Web Services, SqlServer/Oracle)
Disegno:- Come il sistema lo deve fare- Usa il linguaggio dello sviluppatore
Quanto?
- > = _quando_ serve!
- quando fermarsi?
-Quando abbiamo chiarito le complessità che avvertivamo del
sistema e le abbiamo semplificate
- Quando modificando il codice non avvertiamo “attriti” (si xKè il Refactoring si fa in maniera adattiva e non predittiva)
- Design up-front è + facile da fare: svolge ruolo di indirizzo- il Design up-front può ridursi ed il ruolo di indirizzo lo fanno le sole schede CRC
- vedendo e provando il programma l'utente capisce meglio ciò di cui aveva bisogno (nuovi requisiti e req cambiati) e anche noi capiamo cose a cui non avevamo pensato
col tempo arrivano nuovi requisiti: mi serve questo… mi serve quello…
- vi è mai capitato di arrivare alla fine di un progetto, di aver imparato molte cose e dire… “adesso lo progetterei in modo diverso”?
è più difficile cancellare codice che scriverne Es. riunione col capo (poco tempo) o con utenti (poca concentrazione) o doc tecnico per colleghi da convincere/articolo-Tip
il disegno migliora invece di degradare!
Rigido - Fragile - ImmobileFlessibileLocalmente in parti isolate= 1+ metodi, 1+classi strettamente correlate (stesso namespace/assembly) => When the extent of that cascade of change (in moduli correlati) cannot be predicted by the designers or maintainers the impact of the change cannot be estimated.
Robusto- bug in cascata: fisso 1 e compare un altro- + applicazioni sulla stessa Virtual Directory- Portale<= applicazione (javascript/frame)Riutilizzabile- funz. Collegata a… autenticazione, log errori, condivisione connessione,…- user control con dentro SQL
Un altro modo di dire Basso Accoppiamento Altra Coesione
attributi interi ed esterni (predetti da misura di quelli interni con metodo statistico/modello matematico)
Individuare i programmi che hanno i problemi appena descritti
Individuare quali hanno esigenze di evoluzione/complessità (mutabilità dei requisiti, nuovi requisiti, tailoring per nuovi clienti, molti bug da correggere)
Intervenire
- Refactoring del 1° tipo (meccanico) sui punti che + ne hanno bisogno
- Refactoring del 2° tipo (manuale) quando il cliente chiede modifiche
Info da usare per far avvicinare i colleghi al R e altre info utili per migliorarsi.
-Come comprendere e reagire ai feedback del codice?
metriche
predittive e di controllo
attributi interi ed esterni (predetti da misura di quelli interni con metodo statistico/modello matematico)
metriche statiche (complessità, comprensibilità, manutenibilità)
metriche dinamiche (efficienza, affidabilità)
Vil a linea di comando:- La metrica che voglio raccogliere- Il titolo- Il file htmpl di output
Lo faccio per ogni metrica
Con il Copy unisco tutti i risultati in un unico html
e visualizzo il risultato
Ho avuto problemi con la lunghezza del comando (command + arguments) da VS.NET External Tools… e ho risolto specificando la directory iniziale e quindi potendola togliere dal Command
@echo on / pause
==> www.1bot.com
trasformazioni in piccoli passi semplici
applicati con sistematicità e disciplina
velocità->rischio di introdurre bug sottili
Nota: questi sono i sintomi (queste metriche misurano attributi internni per predire quelli esterni)
la malattia: cattivo disegno = rigidità, fragilità, immobilità
la cura: fare refactoring (->basso accoppiamento alta coesione) verificando se "ha senso" (OO, Pattern, LSP, OCP, DIP)
modello iso osi, esempio chat e livelli applicazione e sessione
-> programmazione OO + pratica -> feedback dal codice
- da una parte i dp possono “materializzarsi” spontaneamente nel codice facendo refactoring
- dall’altra funzionano da ispirazione durante il refactoring
- inoltre nuovi dp possono nascere proprio facendo refactoring
- Introdurre il refactoring come attività continua durante la scrittura di codice
- approfondire i principi della programmazione OO e design e applicare il refactoring del 2° tipo
- fare pratica di TDD e applicare TDD+Refactoring di 1° tipo
Shotgun surgery
Codice duplicato
Cambiamenti divergenti
Commenti
Generalizzazione speculativa