Refactoring: differenze tra le versioni

Versione delle 17:43, 15 gen 2013

Versione delle 17:59, 15 gen 2013

Riga 5:

Benché il concetto generale di refactoring possa essere applicato in qualsiasi contesto di sviluppo software, nelle [[metodologie agili]] e nell'[[extreme programming]] il termine è usato prevalentemente nel contesto della [[programmazione orientata agli oggetti|orientato agli oggetti]]. In questa accezione stretta (proposta originariamente da [[Martin Fowler]], che è tuttora uno degli autori più influenti sull'argomento),<ref>Fowler è tra l'altro l'autore del primo libro sull'argomento: ''Refactoring: Improving the Design of Existing Code'', e mantiene il sito [http://refactoring.com refactoring.com], che raccoglie molte risorse sul refactoring.</ref> il refactoring è in genere motivato dalla rilevazione di un ''[[code smell]]''.<ref name="fowlerbook">V. M. Fowler, ''Refactoring''</ref> Per esempio, un metodo potrebbe apparire eccessivamente lungo e complesso, o contenere molto codice duplicato anche in un altro metodo. L'azione di refactoring mira a eliminare il problema (per esempio portando a fattor comune il codice duplicato) attraverso una serie di "micro-passi" il più possibile semplici.<ref name="fowlerbook"/> Il requisito di semplicità delle singole modifiche ha due giustificazioni: ridurre il rischio di introdurre errori con la modifica, e rendere ipotizzabile l'esecuzione automatica della modifica stessa da parte di strumenti integrati negli [[Integrated development environment|IDE]]. Gran parte della letteratura sul refactoring descrive tipi di micro-modifiche di uso comune che, combinate in sequenza, possono portare a ristrutturazioni anche radicali del software, e molte delle azioni di refactoring proposte in letteratura sono implementate da IDE moderni come [[Eclipse]].

Il refactoring è un elemento integrante di molti processi di sviluppo fortemente basati su [[automazione del collaudo del software|test automatici]]; per esempio, lo [[test driven development|sviluppo basato su test]] (TDD) prevede una fase (obbligatoria ed esplicita) di refactoring al termine di ogni ciclo di modifica. Fra i due concetti esiste infatti un legame molto stretto. IRieseguendo eventuali test automatici sonoal utilitemine durante il refactoring perché, attivati dopodi ogni micro-modifica, contribuisconosi aha garantire cheinfatti la modificaconferma in questioneche non abbiasiano introdottostati introdotti errori., Grazieanche a questafronte protezione dagli errori, anchedi modifiche estremamenteparticolarmente invasive (come lo spostamento di intere porzioni di codice dafra unaclassi classeo all'altra),la chemodifica indelle assenzarelazioni di test sarebbero probabilmente percepite come troppo rischiose, possono essere eseguite con un buon grado di confidenzaereditarietà).

==Refactoring e test automatici==

Il refactoring è un elemento integrante di molti processi di sviluppo fortemente basati su [[automazione del collaudo del software|test automatici]]; per esempio, lo [[test driven development|sviluppo basato su test]] (TDD) prevede una fase (obbligatoria ed esplicita) di refactoring al termine di ogni ciclo di modifica. Fra i due concetti esiste infatti un legame molto stretto. I test automatici sono utili durante il refactoring perché, attivati dopo ogni micro-modifica, contribuiscono a garantire che la modifica in questione non abbia introdotto errori. Grazie a questa protezione dagli errori, anche modifiche estremamente invasive (come lo spostamento di intere porzioni di codice da una classe all'altra), che in assenza di test sarebbero probabilmente percepite come troppo rischiose, possono essere eseguite con un buon grado di confidenza.

== Software per il refactoring ==