REFERINTE

PSS - Programming Guidance Basics 1.7.doc, capitolul Concepts, sectiunea

refactoring
Books: Martin Fowler Refactoring: Improving the Design of Existing Code
Martin Fowler:
- http://refactoring.com/
- http://refactoring.com/catalog/index.html
- http://refactoring.com/sources.html
o ATENTIE: intre timp Core J2EE Patterns au sugerat un re-design! Cautati
JEE Rethinking

DEFINITIE ORTODOXA
Refactoring is a disciplined technique for RESTRUCTURING AN EXISTING BODY OF CODE,
ALTERING ITS INTERNAL STRUCTURE WITHOUT CHANGING ITS EXTERNAL BEHAVIOR.
Its heart is a series of small behavior preserving transformations. Each transformation (called a
'refactoring') does little, but a sequence of transformations can produce a significant restructuring.
Since each refactoring is small, it's less likely to go wrong. The system is also kept fully
working after each small refactoring, reducing the chances that a system can get seriously
broken during the restructuring. (Martin Fowler)
Atribute metoda Refactoring:
- se aplica pe cod/implementare EXISTENTA
- pastreaza partea de FUNCTIONALITATE
- DESIGN ++ prin
o O serie de transformari mai mici
Impact profund, daca vin intr-un set coerent
Risc si costuri mai scazute , pentru ca se face ITERATIV = sistemul
trebuie sa fie functional dupa fiecare transformare
~ o serie de mici interventii chirughicale , nu una masiva
Care sunt atributele pentru CATEGORIA GENERALA DE METODE?
- se aplica pe cod/implementare EXISTENTA
- pastreaza partea de FUNCTIONALITATE
- DESIGN ++ prin diverse mijloace
o Refactoring (vezi mai sus)
o Re-design
o Re-Architecting

CONTEXTUL GENERAL
In realitate Refactoring-ul este o metoda intr-un context mai amplu, care NU poate fi aplicata
independent, ci impreuna cu altele asemanatoare in functie de NECESITATI.

MOTIVATIE
Technical Debt si consecinte
In SW Dev., design-ul tinde in timp sa nu mai fie potrivit sau sa se deterioreze. Daca nu luam
masuri speciale, asta se intampla SIGUR, by default.
Concept: Daca o aplicatie/system software ajunge sa aibe un design deteriorate si/sau nepotrivit
avem TECHNICAL DEBT.
Consecinte: Daca nu este tratat, in timp TECHNICAL DEBT creste de la un proiect la altul pana
ajungem sa avem probleme de:
- Scade scalabilitatea si mentenabilitatea necesare
o Mai mult effort, timp , bani
- Scade calitatea (cod fragil)
- Cresc costurile (vezimai sus)
- Proiectele pe acelasi produs au probleme (de start) din ce in ce mai mari in timp
- Poate fi necesara rescriere (RE-WRITE), care este costisitoare

Categorii de Technical Debt

Sunt doua categorii mari
C1 Design deteriorat
- avem Spaghetti Code in loc de Clean Code , cu toate consecintele de fragilitate a
codului vezi mai sus
C2 Design ne-adaptat
- presupunem ca am inclus in produs functionalitatile din CR1, CR2 . CRN, si avem
<Design N> destul de bun
- Primim <CR N+1> si constatam ca nu putem adauga / modifica confortabil peste <Design
N> pentru ca nu a fost gandit pentru asa ceva
- Daca NU ADAPTAM design-ul legacy producem automat technical debt

Nivele de design (sensul extins)

Avem cel putin 3 nivele de design in sensul extins (toate aspectele solutiei) - de intretinut:
- Clean Code
- Design propriu-zis
- Arhitectura
Diferenta este data de IMPORTANTA ,in primul rand, si ,in al doilea rand, de granularitatea
DECIZIILOR LEGATE DE SOLUTIE incapsulate in nivel.
Reparatia se face corespunzator nivelului.
Clean code prin Refactoring
Design Re-design
Architecture Re-Architecture

FOARTE IMPORTANT toate nivelele conteaza

Problemele la un nivel inferior afecteaza nivelele superioare
Spaghetti code (Design + Architecture) afectate
Poor Design Architecture afectata
Explicatiile sunt elementare:
- combinatia si repetarea de problemelor mici dau probleme mari
- un cod INCALCIT scade vizibilitatea pentru intretinerea design-ului si arhitecturii
Si reciproca este valabila e chiar mai importanta !!
Good Architecture Poor Design si Spaghetti code au mai putin efect
Good Design Spaghetti code are mai putin efect negativ
Explicatia e simpla: lucrurile rele se intampla la scala mai redusa!!!

METODE DE TRATARE
ATENTIE: In fiecare ciontext dat avem un Technical Debt specific pentru tratarea lor pot aparea
separate sau impreuna toate metodele de mai jos. Alegerea metodelor este IN FUNCTIE DE
NECESITATI.
Care este CATEGORIA GENERALA DE METODE?
- se aplica pe cod/implementare EXISTENTA
- pastreaza partea de FUNCTIONALITATE
- DESIGN ++ prin diverse mijloace:
o Refactoring
o Re-design
o Re-Architecting
Metoda \ Cum?
Refactoring
Re-design
Re-Architecting

Doar modificare
Da
Da, posibil
Da, posibil

Re-Write
Nu (de obicei)
Da, posibil
Da, foarte posibil

RE-WRITE-ul (~ RE-WORK) este mai costisitoare decat corectarea prin modificare. Bineinteles,
atunci cand situatia este prea grava, re-write-ul ajunge sa fie mai ieftin.
Daca am face o metafora legata de meicina: re-write-ul ar fi o operatie chirurgicala masiva , iar
modificarea operatii mai mici , tratament sau preventie.
Rezulta ca cel mai IEFTINA metoda este refactoring-ul. Este adevarat, nu sunt echivalente cele
3, dar un SPAGHETTI CODE poate ascunde sau genera greseli de design si arhitectura!

REFACTORING Knowledge
In diverse surse (carti, site-uri, etc) vom gasi cunostintele grupate in SETURI DE
REFACTORING-uri.
Dar ce este UN REFACTORING?
Este o pereche: anti-pattern (asa nu) + pattern (asa da) + metoda de transformare
Un profesionist din domeniu development ar trebui sa cunoasca principalele perechi asa da/asa
nu pentru a le putea:
- Recunoste (asa nu) si trata (tranzitia catre pattern = asa da)
- Preveni se aplica direct , unde se poate , varianta asa da

REFACTORING si testare
By default, REFACTORING-UL ESTE ASOCIAT CU TESTAREA SI TESTAREA DE REGRESIE
- testez ce am modificat
- testez de regresie partile care folosesc sau sunt afectate de ceea ce am modificat
Testarea Automata poate fi de un mare ajutor pentru Refactoring: orice portiune de cod
acoperita cu cod de test beneficiaza de reducerea efortului de testare si a riscurilor de modificare
Nu intamplator, metodologia Agile promoveaza aplicarea simultana ambelor pratici: Refactoring
si TDD.

REFACTORING si planificare
In principiu, tratarea Technical Debt-ului trebuie sa fie:
- evaluate in ETAPA DE DESIGN a unui proiect software
- si apoi inclusa in PLANUL de PROIECT.
Refactoring-ul fiind o metoda de tratare a TD-ului, trebuie sa fie inclusa in strategia de design
necesara si actvitatile de proiect.
ATENTIE: Micile refactorizari pot fi considerate parte din implementare cu includerea lor in
strategia de testare. DAR, necesitatea aplicarii unor SETURI CONSISTENTE trebuie sa faca
parte din strategia de design si trebuie evaluat la DESIGN TIME.
La fel, ba chiar mai mult, evaluare si planificarea sunt obligatorii daca este vorba de Re-Design
si Re-Architecting.