Prima che uscisse il libro di Martin Fowler "Refactoring: Improveing the Design of Existing Code", abbiamo usato le principali modifiche al codice "rearchitecture" e le modifiche minori "cleanup". IMO, le tecniche di refactoring sono tutte cose di buon senso / ovvietà che abbiamo fatto per sempre.
Pensi che il refactoring sia stato qualcosa di nuovo? Forse solo un modo per ingannare la gestione nell'assegnare il tempo per la pulizia del codice?
Il refactoring è più vecchio delle colline, quindi no, non è niente di nuovo.
E il refactoring non sta pulendo. Beh, può essere, ma non è limitato alla pulizia.
Sta modificando l'architettura della tua applicazione (a grandi o piccole dimensioni) preservando il comportamento.
Ciò significa che, mentre una parte della tua applicazione poteva essere perfettamente pulita e bene ieri, la nuova funzione di oggi richiede la regolazione di quella parte per adattarla alla nuova funzione.
Non vuoi rompere le funzionalità esistenti, quindi modifichi la struttura della tua applicazione mantenendo il comportamento, che è il refactoring.
Ciò detto, indipendentemente dalle modifiche apportate al codice, si dovrebbero sempre eseguire i test ... nel caso.
È solo riordinare il codice. In sostanza, i programmatori (in particolare Martin Fowler) hanno notato che tendevano a svolgere gli stessi compiti ogni volta che riordinavano il loro codice. Hanno definito ed etichettato i metodi di riordino e i problemi associati al codice e presto! Il refactoring è nato.
È lo stesso con i modelli di design - le persone hanno notato che tendevano ad usare sempre gli stessi approcci a problemi particolari. Hanno etichettato e definito gli approcci e ora sembra che tu non sia un vero programmatore a meno che tu non usi solo la stessa dozzina di schemi nel tuo codice.
Non c'è magia per il refactoring; è solo un nuovo gergo per descrivere un vecchio studio.
Facciamo tre cose separate nella nostra azienda, con il tempo assegnato per i tre:
Esempio: divisione di un brutto e illeggibile metodo a 100 righe che fa quattro cose in quattro metodi riutilizzabili, 25 righe ciascuno.
Esempio: rimozione del codice commentato dopo aver verificato che questo codice non è più necessario.
Esempio: aggiunta Culture.Invariant in string.Format (o un'altra cultura che è più appropriata).
Il refactoring aggiunge conoscenza al tuo codice. Se sai che qualcosa viene erroneamente chiamato, gli dai un nome migliore. Se sai che qualcosa può essere fatto meglio, lo cambi in qualcosa di meglio.
Ci sono molti passaggi, piccoli e grandi, che si spera possano portare a un programma migliore.
Sono d'accordo con "refactoring è una parola elaborata per ripulire il tuo codice" ma non con "just". Le persone usano le parole di fantasia per una ragione: a volte perché vogliono sembrare intelligenti, ea volte perché trasmettono un significato più grande o più preciso, e il refactoring IMHO (anche se occasionalmente abusato) si riferisce generalmente a quest'ultimo.
"Pulisci" potrebbe significare qualsiasi cosa, da "riformattazione un po '" a "riscrittura di grossi pezzi".
"Refactoring" significa in particolare qualcosa come "piccole modifiche incrementali al codice, progettate per mantenere la stessa funzionalità, trasformandola in un design migliore". E c'è un corpo di best practice sul tipo di cose che fai: alcune sono ad-hoc, ma ci sono principi generali, come l'uso di test unitari, l'estrazione di parte di funzioni in nuove funzioni o classi, ecc., Che le persone possono e dovrebbero imparare .
Dici "solo la gestione dei trucchi nell'assegnare il tempo per la pulizia del codice". Ma se dire "refactoring" trasmette correttamente il concetto che un investimento costante in chiarezza ora pagherà dividendi in efficienza in futuro, allora non è un "trucco", è una comunicazione chiara ed efficace.
Il refactoring consiste nel codice in quanto la normalizzazione riguarda i dati relazionali. È un processo di astrazione dei concetti in rappresentazioni più pulite, più chiare e più efficienti del loro ruolo nell'applicazione.
Dipende da come comprendi il refactoring dei termini. Per la maggior parte delle persone questo è un processo per migliorare la struttura senza modificare il comportamento. Se sei d'accordo, allora sì è stato fatto molto prima che uscisse questo libro. Lo so, perché ero (tra le altre cose) rinominando le classi, estraendo classi ed estraendo metodi prima che il libro fosse scritto. Non lo chiamavo refactoring, ma in sostanza stavo facendo esattamente la stessa cosa.
Per me personalmente il refactoring è ciò che le persone chiamano ora "refactoring automatico del codice", ovvero supporto per varie tecniche di refactoring all'interno di un IDE. Questo è un miglioramento reale rispetto a quello che stavo facendo prima (che in effetti era molto doloroso). Posso apportare un cambiamento in una classe e non preoccuparmi di come questo influenzerà il resto del software. Penso che Martin abbia formalizzato la tecnica di refactoring fino al punto in cui potrebbe essere rappresentata come un algoritmo e quindi implementata in vari IDE là fuori.
Quindi, se capisci il refactoring come un processo, allora non è una novità. Se la vedi come automazione, allora sì, è un enorme miglioramento. Prova a rinominare alcune classi core (letteralmente, non attraverso le opzioni di refactoring del tuo IDE) in un progetto abbastanza grande per capire perché:)
Il refactoring è in effetti il codice "cleanup", ma anche la ristrutturazione del codice. Nella mia squadra il refactoring è di solito il secondo. Quando abbiamo un caso di "refactoring", dedichiamo tempo per ristrutturare il nostro codice, ad es. per renderlo allineato con una nuova architettura, o modello di informazione, o per renderlo più efficiente.
Il codice "pulizia" è qualcosa che facciamo continuamente senza tempo appositamente assegnato. Per me, "cleanup" di solito rinomina, pulisce i commenti, ecc.
Direi di no.
Potrebbero esserci ripulimenti nel processo di refactoring ma non è essenziale.
Pulizia viene fornito con l'assunto che il codice precedente non è pulito. In realtà, gli sviluppatori rifattorizzano il loro codice anche se il codice originale è già pulito.
DRY è un elemento chiave dietro il refactoring.
Quando si aggiungono nuovi codici a una base di codice esistente, il refactoring viene eseguito naturalmente a causa del principio DRY.
Solo il mio 0.02
Pulire il tuo codice è come mettere a posto la tua casa, il refactoring è come abbattere un muro e magari metterlo da qualche altra parte
Quando qualcun altro ripulisce la tua casa, non riesci a trovare nulla perché l'obiettivo è ottenere le cose pulite e fuori strada. Il refactoring costruiva ed etichettava stanze, armadi, armadi, scaffali, bidoni, ecc. Conserva ancora la maggior parte delle stesse cose (puoi ancora preparare un panino al formaggio grigliato in cucina e mangiarlo nel soggiorno), ma dovresti farlo più facile da trovare e possibilmente avere posti efficienti dove mettere cose nuove.
Il termine "refactoring" è elegantemente mutuato dall'algebra. Significa semplificare i termini per produrre lo stesso risultato. Non solo elegante, era rivoluzionario: richiedeva un approccio al codice molto complesso, a un livello che sorprendeva molti. E quindi il termine stesso era significativo e utile.
No. Il refactoring sta migliorando la struttura senza modificare il comportamento. Il refactoring in senso stretto implica una buona disciplina di prova. Questo non è necessariamente necessario quando "pulisci le cose".
I due si sovrappongono leggermente ai bordi, ma per me è la differenza tra pulire la casa e rimodellare la casa. La pulizia, per me, non implica cambiamenti strutturali, mentre il refactoring lo fa.
"Refactoring" è in realtà la stessa cosa di "rearchitecture", ma con una connotazione più strong di "nessuna modifica di funzionalità". È anche più chiaro in termini di obiettivo della re-architettura, che spesso è quello di "scomporre" il codice comune in blocchi riutilizzabili.
Leggi altre domande sui tag design refactoring terminology