Mappa degli OORPMappa degli OORP
Tests: Your Life Insurance
Detailed Model Capture
Initial Understanding
First Contact
Setting Direction
Migration Strategies
Detecting Duplicated Code
Redistribute Responsibilities
Transform Conditionals to Polymorphism
Detailed Model CaptureDetailed Model Capture
Tie Code and Questions
Refactor to Understand
Step through the Execution
Look for the Contracts
Learn from the Past
Tie Code and QuestionsTie Code and Questions Scopo: Appuntare domande e risposte,
riguardanti le attività di reingegnerizzazione, sincronizzate con il codice memorizzandole direttamente nel file di origine.
Problema: Come tenere traccia delle informazioni apprese del sistema?
Soluzione: commentare il codice in modo diretto e immediato
Tie Code and Questions Tie Code and Questions (1)(1) Due modalità per commentare il codice:1. Comment-Based Annotations:
2. Method-Based Annotations:
Dichiarando un metodo globale che ha come argomento una stringa e il corpo vuoto.
Tie Code and Questions Tie Code and Questions (1)(1)
ABAP/4 – Migrazione da SAP BI a SAP BI-IP
Tie Code and Questions Tie Code and Questions (2)(2) Note:
- Registrare i commenti più vicino possibile al codice a cui si riferiscono;
- Le annotazioni possono essere domande, ipotesi, liste todo, elenchi o semplici osservazioni;
- Utilizzare convenzioni per le annotazioni, specificando “chi” (#by:) ha scritto il commento, “per chi”(#to:) e “quando” (#on:);
- Se si conosce la risposta ad una domanda posta tramite annotazione è indispesabile aggiornare immediatamente i commenti fornendo una risposta corretta
- Per migliorare la leggibilità è buona pratica utilizzare sempre la stessa lingua per i commenti.
Tie Code and Questions Tie Code and Questions (3)(3) Pro:2.Sincronizzazione Naturale3.Migliora la comunicazione del Team4.Minimizza Descrizione di Contesto
Contro:7.Non esiste una notifica automatica 8.Va contro i principi dei team gerarchici
Tie Code and Questions Tie Code and Questions (4)(4) Difficoltà:
S Individuare la giusta granularità delle informazioni: non bisogna essere troppo concisi o troppo prolissi;
r Motivare il programmatore a scrivere commenti: il programmatore non ama scrivere commenti e/o documentazione;
n Fornire risposte di qualità ai commenti;
n Eliminare le annotazioni: per farlo si possono utilizzare tools che filtrano i commenti.
Tie Code and Questions Tie Code and Questions (5)(5) Utilità: Questo pattern torna utile in quanto riduce
l’effort speso per mantenere sincronizzati documentazione e codice sorgente.
Patterns Correlati:Le annotazioni spesso portano al refactoring del codice
per questo motivo Tie Code and Questions lavora bene con il pattern Refactor to Understand. Ovviamente il refactoring può portare all’inserimento di nuove annotazioni
Tie Code and Questions
Refactor to Understand
Refactor to UnderstandRefactor to Understand
Scopo: Fare refactoring del sistema in modo iterativo al fine di convalidare e verificare la conoscenza che abbiamo del sistema.
Problema: Come faccio a decifrare codice criptato?
Soluzione: Facendo refactoring fino a quando non ha più senso
Refactor to Understand Refactor to Understand (1)(1) Note:
- Tenere sempre in considerazione che l’obiettivo è capire il funzionamento del sistema e non migliorare il codice;
- Lavorare su una copia del codice;
- Compilare spesso il codice dopo il refactoring o se disponibile eseguire i test per verificarne la correttezza dopo le modifiche.
-
-
Tie Code and Questions
Refactor to Understand
Write Teststo Understand
Refactor to Understand Refactor to Understand (2)(2) Azioni di refactoring:
o Rinominare attributi, metodi e classi rendendo le etichette pienamente significative;
n Rimuovere codice duplicato;
n Modificare il corpo di metodi in modo da ottenere un consistente livello di astrazione.
Refactor to Understand Refactor to Understand (3)(3) Pro: Apprendimento design: non solo si
apprende il funzionamento del sistema ma anche la struttura del codice
r Validazione Incrementale: un refactoring iterativo aiuta a validare il sistema in modo incrementale
Contro:S Rischio di introdurre errori nel codice
Refactor to Understand Refactor to Understand (4)(4) Difficoltà:
S Il refactoring manuale risulta rischioso e tedioso, per questo è indispensabile il supporto di un tool per il refactoring; automatizzato ad esempio Refactoring Browser;
s Accettare i cambiamenti: non sempre le organizzazioni accettano i cambiamenti individuati per il refactoring.
i Quando fermarsi: bisogna essere consapevoli che lo scopo è apprendere il sistema e non migliorare il codice. L’attività finisce quando il sistema è stato compreso in tutte le sue parti.
Refactor to Understand Refactor to Understand (5)(5) Patterns Correlati:t Refactor to Understand lavora bene con
Tie code and Questions perché le annotazioni possono suggerire azioni di refactoring.
o Altro pattern correlato è Write Test to Understand; infatti risulta indispensabile una convalida frequente del codice modificato
Step through the Step through the ExecutionExecution Scopo: Capire come gli oggetti collaborano tra
loro;
Problema: Come capire quali oggetti sono istanziati al run-time e come questi collaborano?
Soluzione: Eseguire scenari d’uso noti utilizzando il debbuger in modo tale da osservare quali oggetti vengono istanziati e come essi collaborano tra loro.
Step through the Step through the Execution(1)Execution(1) Note: 2. Essendo questa attività time-consuming è
indispensabile focalizzare l’analisi su uno specifico aspetto del sistema che risulta difficile da comprendere;
4. Inserire Breackpoints per interrompere l’esecuzione nei punti di interesse;
6. Modificare lo stato interno di un oggetto per vedere come sono attivati percorsi di esecuzioni alternativi.
Step through the Step through the Execution(2)Execution(2) Pro: 2. Vista Realistica: Si ottiene un quadro preciso di come lo
scenario si svolge; Si può ispezionare lo stato interno di oggetti coinvolti; Si può verificare come gli oggetti collaborano e in quali circostanze
3. Gestisce complessità: Su piccola scala è possibile dedurre le collaborazioni, ma su grande scala l’unico modo è studiare l’execution trace.
Contro: 5. Scenario-Based: non è possibile applicare questo pattern
all’intero sistema ma solo a singoli scenari in quanto è un’attività time-consuming
6. Ristretta applicabilità: molte volte per motivi di concorrenza non si ha il tempo per poter effettuare quest’attività
Step through the Step through the Execution(3)Execution(3) Difficoltà:Dipendenza con i tools: è necessario
utilizzare un buon debugger, che consenta di aggiungere e rimuovere breakpoints dinamicamente e di visualizzare lo stato interno di un oggetto
Look for the ContractsLook for the Contracts
Scopo: Dedurre l’uso corretto di una interfaccia
studiano il modo in cui i client la utilizzano
Soluzione: Analizzare tutti i metodi, chiamate di metodi, costruttori, etc.
Look for the Contracts Look for the Contracts (2)(2) Note:S Guardare i metodi chiave;d Guardare le constructor calls: per capire come e
quando vengono istanziati oggetti di una particolare classe (prestando attenzione ai parametri passati al costruttore)
o Guardare i template o hook method: per capire come è specializzata una classe;
u Guardare metodi protected che sono sovrascritti da sottoclassi
c Guardare le Super Calls
Look for the Contracts Look for the Contracts (3)(3) Pro: Ci si può fidare più del codice sorgente
che della documentazione (molte volte non c’è allineamento tra codice e documentazione)
Contro: Risulta difficile identificare tutte le classi
che implementano una determinata interfaccia
Learn from the PastLearn from the Past Scopo: Confrontare le diverse versione del
software per studiare la sua evoluzione
Problema: Come è evoluto il sistema? E qual è la sua stabilità?
Soluzione: Confrontare le diverse versioni rilasciate, individuano eventuali funzionalità rimosse o aggiunte
Learn from the Past (2)Learn from the Past (2)
Note:S L’obiettivo è capire come il sistema è evoluto
e quali parti sono stabili o meno;n La rimozione di porzioni di software è indice
di un design alterato del sistema;p Frequenti azioni di refactoring indicano
l’instabilità del design;l Azioni di refactoring seguite da un periodo
di stabilità indicano stabilità del design.
Learn from the Past (3)Learn from the Past (3) Pro: 2. Si concentra su artefatti importanti del design perché
i cambiamenti significativi permettono di comprendere meglio il design stesso
3. Fornisce una visione obiettiva del sistema Contro: 5. Richiede notevole esperienza6. Richiede il supporto di tool
a) Strumenti per il calcolo di metricheb) Strumenti di Configuration Management Systemc) Un browser per risalire al codice
Learn from the Past (3)Learn from the Past (3) Difficoltà: Difficoltà nel ricostruire il processo di cambiamento
di un pezzo di codice modificato molte volte;
ConclusioniConclusioni
Questo cluster di pattern insieme con l’initial Understanding permette di pianificare le attività di Reverse Engineering
Top Related