Reguli de refactoring

Problema de lizibilitate și mentenabilitate a codului(daca nu e usor de inteles si de modificat) e un code smell care de obicei ascunde alte code smells, e bine sa poti recunoaste aceste code smells si sa cunosti solutii de refactoring pentru ele. IDE-ul poate contine un tool care sa detecteze aceste code smells, code review poata fi alta solutie pentru detectarea acestora pe care IDE-ul nu le poate detecta. Code review-ul e de asemenea si o metoda de a te perfectiona chiar daca iti face altcineva code review sau daca faci tu code review, motivul pentru care am observat ca nu se face code review unde nu se face e lipsa de timp si graba.

Cateva reguli de refactoring utilizate la code review si in scrierea codului:

1.) Replace Nested Conditional with Guard Clauses.Daca ai if in if pe mai multe nivele de imbricare, asta se poate refactoriza intr-o lista plata de instructiuni conditionale. De exemplu varianta ne-refactorizata: Dupa refactorizare:

2.) Decompose Conditional. Daca ai un if cu multe conditii, tot sirul de conditii se poate pune intr-o metoda cu nume sugestiv si sa se foloseasca in if aceea metoda, astfel incat sa nu trebuiasca sa parcurgi toate conditiile ca sa iti dai seama cand se executa if-ul respectiv, ci sa iti dai seama din numele metodei. De exemplu varianta ne-refactorizata: Dupa refactorizare:

3.) Extract Method. Daca ai un if cu un bloc de instructiuni, ai putea sa extragi acel bloc de instructiuni intr-o metoda cu un nume sugestiv astfel incat sa intelegi codul fara sa parcurgi secvential toate instructiunile din bloc, ci doar sa te uiti la o interfata high level, o semnatura de metoda. Extract Method se poate aplica ca si principiu de refactorizare pentru orice bloc de instructiuni cu scop comun nu doar in cazul instructiuni if.

Cand scrii cod te concentrezi sa rezolvi problema in timp cat mai scurt, si mai putin pe cat de usor de inteles este acel cod de catre altcineva sau cat de mentenabil e.

O lista completa de code smells si solutii de refactoring pentru ele, foarte bine structurata, pe care puteti sa le luati in considerare cand scrieti code sau faceti code review altcuiva:

SourceMaking

De asemenea code smells duc la technical debt

Aceste principii se pot regasi si in cartea si seria video Clean Code de Robert C. Martin dar si in articolele lui Martin Fowler asigurand alaturi de teste unitare(unit testing) calitatea si mentenabilitatea produsului software.

Testele unitare sustin procesul de refactoring, acesta se poate face mai usor fara sa stricam codul functional, deoarece de fiecare data cand modificam codul putem rula testele unitare si sa ne asiguram ca nu am stricat ceva functional in cod.