Autore Kevin Rutherford sui modelli di refactoring di questa settimana refcard

Questa settimana, DZone prosegue una serie di pattern-correlato Refcardz con i modelli di refactoring, scritto da Kevin Rutherford, che è anche l'autore del libro Refactoring in Ruby . Questa scheda fornisce una introduzione al refactoring, così come la descrizione dettagliata dei vari modelli di refactoring e un elenco di strumenti utili per il refactoring varie lingue di codifica. Kevin ha preso pochi minuti per rispondere ad alcune domande relative alle sue esperienze come sviluppatore, così come un paio di pareri di esperti sui problemi e le pratiche di refactoring efficace.

DZone: Ehi Kevin! Grazie per le ultime refcard authoring DZone sul refactoring. Parlaci un po 'della tua esperienza con questo argomento.

Kevin Rutherford: Sono stato lo sviluppo di software dal 1975, e credo che mi sono sempre 
stati interessati a qualità del codice, e nel processo di creazione e mantenimento di software di alta qualità. Già negli anni Ottanta, quando ho lavorato su estensioni di alta sicurezza al kernel Unix, abbiamo scoperto che il refactoring è una parte essenziale di mantenere il nostro codice pulito e gestibile. Naturalmente il termine "refactoring" non era stato inventato allora, e non abbiamo avuto le ricette dei libri di testo o nomi di modello per quello che abbiamo fatto, ma col senno di poi era sicuramente refactoring, e sicuramente tenuto in vita quel progetto.

DZone: Che cosa hai lavorato ultimamente?

Kevin Rutherford:  La mia attuale lista di progetti, un buon mix di TDD formazione, agile 
coaching e lo sviluppo Ruby / Rails. Attualmente il mio tempo si divide quasi equamente tra questi tre tipi di client.

DZone: Come descriveresti questa carta in una sola frase?

Kevin Rutherford:  Si tratta di una rapida panoramica di ciò che è di circa il refactoring in pratica, con un sacco di codice di esempio pratico in Java.

DZone : Sembra che la decisione di refactoring, piuttosto che ricominciare da zero può essere dura.Potete suggerire alcuni criteri per decidere tra il refactoring e la riscrittura?

Kevin Rutherford : Refactoring è "di solito" preferibile, perché la quantità enorme di conoscenze tacite ed implicite sepolto nella base di codice corrente fa ripartendo una scelta ad alto rischio. Vorrei riscrivere se dovessi passare a un nuovo linguaggio, framework o tecnologia, ma nella maggior parte dei casi gli altri cerco di refactoring. Meglio ancora, cerco di evitare che il futuro infernale per mantenere il codice pulito adesso. Piccolo ed è spesso l'approccio migliore per il refactoring.

DZone: In quali situazioni è più difficile per gli sviluppatori di refactoring del codice, e qual è la soluzione generale per quelle situazioni?

Kevin Rutherford:  Refactoring è più difficile quando la copertura di test è basso, o quando ogni frammento di codice è strettamente collegato a molti altri, o quando la conoscenza di tecnologie esterne si è infiltrata in tutto il cuore del codice di base. La prima priorità per uscire da queste situazioni è una buona copertura da una suite di test veloci, quindi è lì che iniziano sempre. E poi traspare sempre che, al fine di creare quei test, devo nascondere tecnologie esterne dietro opportune astrazioni, e in generale separare le varie funzioni e le responsabilità del 
codice. In generale, il codice è sicuro solo il refactoring quando si ha una buona, la copertura veloce di test e che la copertura di test può essere raggiunto solo in ben progettato codice composto da tanti piccoli pezzi disaccoppiati.

Corso Java - Corsi Java - Corsi programmazione Java

 Corso programmazione Android - Certificazione Android