Refactoring ( eng. refactoring ), sau reproiectarea codului, revizuirea codului, transformarea echivalentă a algoritmilor - procesul de modificare a structurii interne a programului , fără a afecta comportamentul său extern și care vizează facilitarea înțelegerii muncii sale [1] [2 ] ] . Refactorizarea se bazează pe o serie de mici transformări echivalente (adică, care păstrează comportamentul). Deoarece fiecare transformare este mică, este mai ușor pentru programator să-și urmărească corectitudinea și, în același timp, întreaga secvență poate duce la o restructurare semnificativă a programului și poate îmbunătăți consistența și claritatea acestuia.
Scopul refactorizării este de a face codul programului mai ușor de înțeles; fără aceasta, refactorizarea nu poate fi considerată reușită.
Refactorizarea ar trebui să fie distinsă de optimizarea performanței . La fel ca refactorizarea, optimizarea de obicei nu schimbă comportamentul programului, ci doar accelerează activitatea acestuia. Dar optimizarea face adesea codul mai greu de înțeles, ceea ce este opusul refactorizării [3] .
Pe de altă parte, refactorizarea trebuie, de asemenea, diferențiată de reinginerie , care este efectuată pentru a extinde funcționalitatea software-ului. De regulă, refactorizările majore preced reinginerirea.
Refactorizarea ar trebui să fie aplicată constant atunci când se dezvoltă codul. Principalele stimulente pentru implementarea sa sunt următoarele sarcini:
În multe feluri, atunci când refactorizează, este mai bine să te bazezi pe intuiție bazată pe experiență. Cu toate acestea, există câteva mirosuri vizibile de cod care necesită refactorizare :
În programare, termenul de refactorizare înseamnă schimbarea codului sursă al unui program fără a modifica comportamentul său extern. În Extreme Programming și în alte metodologii agile, refactorizarea este o parte integrantă a ciclului de dezvoltare a software-ului: dezvoltatorii alternează între crearea de noi teste și funcționalități și apoi refactorizarea codului pentru a-i îmbunătăți consistența și transparența. Testarea unitară automată se asigură că refactorizarea nu distruge funcționalitatea existentă.
Refactorizarea nu este destinată inițial să remedieze erori și să adauge noi funcționalități, nu schimbă deloc comportamentul software-ului [3] și ajută la evitarea erorilor și facilitează adăugarea de funcționalități. Se realizează pentru a îmbunătăți înțelegerea codului sau pentru a-i schimba structura, pentru a elimina „codul mort” - toate acestea pentru a face codul mai ușor de întreținut și dezvoltat în viitor. În special, adăugarea unui comportament nou la un program poate fi dificilă cu o structură existentă, caz în care dezvoltatorul poate efectua refactorizarea necesară înainte de a adăuga noua funcționalitate.
Aceasta ar putea fi mutarea unui câmp de la o clasă la alta, scoaterea unei bucăți de cod dintr- o metodă și transformarea acesteia într-o metodă independentă sau chiar mutarea codului printr-o ierarhie de clasă. Fiecare pas individual poate părea elementar, dar efectul cumulativ al unor astfel de mici modificări poate îmbunătăți radical un proiect sau chiar poate preveni destramarea unui program prost conceput.
Cele mai frecvent utilizate metode de refactorizare [4] sunt:
Esența modificării semnăturii unei metode este adăugarea, modificarea sau eliminarea unui parametru de metodă. După schimbarea semnăturii metodei, este necesar să corectați apelurile către aceasta în codul tuturor clienților. Această modificare poate afecta interfața externă a programului, în plus, nu întotdeauna dezvoltatorul care modifică interfața are acces la toți clienții acestei interfețe, așa că poate fi necesară o anumită formă de înregistrare a modificărilor de interfață pentru transferul ulterior al acestora împreună cu noua versiune a programului.
Dacă o clasă are un câmp public, trebuie să îl faceți privat și să furnizați metode accesorii. După „Încapsularea câmpului ” se aplică adesea „ Relocarea metodei ” .
Extragerea metodei constă în extragerea fragmentelor separate dintr-un cod lung și/sau care necesită comentarii de cod și transformarea lor în metode separate, cu înlocuirea apelurilor corespunzătoare la locurile de utilizare. În acest caz, se aplică regula: dacă o bucată de cod necesită un comentariu despre ceea ce face, atunci ar trebui să fie separată într-o metodă separată. De asemenea, o regulă: o metodă nu trebuie să ocupe mai mult de un ecran (25-50 de linii, în funcție de condițiile de editare), altfel unele dintre fragmentele sale au valoare independentă și sunt supuse selecției. Din analiza conexiunilor fragmentului selectat cu contextul înconjurător, se face o concluzie despre lista de parametri ai noii metode și variabilele sale locale.
Relocarea metodei se aplică unei metode care se referă mai des la o clasă diferită de cea în care rezidă.
O instrucțiune condiționată cu mai multe ramuri este înlocuită cu un apel la o metodă polimorfă a unei clase de bază care are subclase pentru fiecare ramură a instrucțiunii originale. Alegerea ramurii este implicită, în funcție de instanța subclasei căreia i s-a adresat apelul.
Principii de baza:
Criterii tehnice pentru instrumentele de refactorizare:
Criterii practice pentru instrumentele de refactorizare: