Refactoring: non è solo una parolaccia per ripulire il tuo codice? [chiuso]

21

Chiuso . Questa domanda è basata sull'opinione . Al momento non accetta risposte.

Vuoi migliorare questa domanda? Aggiorna la domanda in modo che possa essere risolta con fatti e citazioni modificando questo post .

Chiuso 4 anni fa .

Prima che venisse pubblicato il libro di Martin Fowler "Refactoring: Improveing the Existing of Existing Code", chiamavamo grandi cambiamenti al codice "rearchitecture" e cambiamenti minori "cleanup". IMO, le tecniche di refactoring sono tutte cose di buon senso / ovvie che facciamo da sempre.

Pensi che il refactoring sia mai stato qualcosa di nuovo? Forse è solo un modo per ingannare il management nell'allocare tempo per la pulizia del codice?

design refactoring terminology

— Chuck Stephanski
fonte

Quando dici "prima che uscisse il libro", presumo che ti riferisci al libro di Martin Folwer è corretto?

— AlexC

-1: Qual è l'utilità di questa domanda?

— Jim G.

Sì, il libro di Fowler.

— Chuck Stephanski,

43

Il refactoring è più vecchio delle colline, quindi no, non è niente di nuovo.

E il refactoring non sta pulendo. Bene, può essere, ma non si limita alla pulizia.

Sta regolando l'architettura dell'applicazione (su larga o piccola scala) preservando il comportamento.

Ciò significa che mentre alcune parti dell'applicazione potrebbero essere state perfettamente pulite e soddisfacenti ieri, la nuova funzionalità di oggi richiede di regolare quella parte per adattarla alla nuova funzionalità.

Non si desidera interrompere la funzionalità esistente, quindi si regola la struttura dell'applicazione preservando il comportamento, che è il refactoring.

Detto questo, indipendentemente dalle modifiche apportate al codice, si dovrebbe sempre eseguire i suoi test ... per ogni evenienza.

— Frank Shearar
fonte

1

Newtopian: questo è un punto vitale. Se non hai eseguito i test, non hai idea di aver hackerato casualmente qualcosa o di aver effettuato effettivamente il refactoring . (E ovviamente, hai bisogno di una suite di test adeguata!)

— Frank Shearar,

9

Sta solo riordinando il codice. In sostanza, i programmatori (specialmente Martin Fowler) notarono 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 di codice associati e presto! Nasce il refactoring.

È lo stesso con i modelli di progettazione: le persone hanno notato che tendevano a 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 mai la stessa dozzina di schemi nel tuo codice.

Non c'è magia nel refactoring; è solo un nuovo insieme di gergo per descrivere una vecchia pratica.

— Formica
fonte

William Opdyke, 1992: Refactoring di strutture orientate agli oggetti . Fowler & Beck & friends hanno reso popolare il refactoring. Jon Brant e Don Roberts hanno implementato il primo strumento automatizzato qualche tempo prima del 1999. Quindi il "nuovo set di gergo" non è molto preciso.

— Frank Shearar,

Se si accetta che la programmazione informatica è in corso da quando Ada Lovelace a metà del 1800, allora sì, è un insieme relativamente nuovo di gergo.

— Formica

1

Penso che la differenza sia con Design Patterns che quasi tutti gli sviluppatori hanno appreso alcuni nuovi modelli e quindi alcuni nuovi strumenti del mestiere dal libro. Con Refactoring non mi sento come se qualcuno avesse davvero imparato qualcosa. C'è un valore secondario nel dare un nome a qualcosa (e il confronto dei modelli di progettazione regge lì) ma avrebbe potuto farlo con un post sul blog.

— Chuck Stephanski,

Anzi, ho detto che era un nuovo gergo ... rispetto al calcolo lambda.

— Frank Shearar,

@Chuck, hai letto il libro, Refactoring? In tal caso, sarei molto sorpreso se non imparassi qualcosa di nuovo da esso.

— Marcie,

7

Facciamo tre cose separate nella nostra azienda, con tempo assegnato per le tre:

Refactoring: consiste nel cambiare la struttura del codice, mantenendo così il comportamento.

Esempio: dividere un metodo brutto e illeggibile di 100 linee che fa quattro cose in quattro metodi riutilizzabili, 25 linee ciascuno.

Pulizia: consiste nel fare piccole modifiche per rendere il codice più leggibile senza modificare né il suo comportamento né la sua struttura.

Esempio: rimozione del codice commentato dopo aver verificato che questo codice non è più necessario.

Applicazione delle regole StyleCop / FxCop: consiste nel verificare se il codice corrisponde all'insieme predefinito delle regole StyleCop o FxCop e, in caso contrario, modificarlo in modo che corrisponda a tali regole.

Esempio: aggiunta Culture.Invariantin string.Format(o un'altra cultura che è più appropriata).

Quindi, nel mio caso, il refactoring è qualcosa di molto diverso dalla pulizia . Quando eseguo la pulizia, non devo eseguire nuovamente i test unitari: se il codice ha funzionato prima, lo farà lavorare dopo la pulizia. In altre parole, non è perché ho rimosso una riga vuota o aggiunto un commento che il codice smetterà di funzionare. D'altra parte, quando refactoring parti complicate di un vecchio codice, posso fare alcuni errori, quindi devo eseguire unit test dopo il refactoring.

— Arseni Mourzenko
fonte

4

Anche se concordo sul fatto che esiste una differenza fondamentale tra clean-up e re-factoring, ci sono molti casi in cui questa linea si confonde un po '. Rimuovere una classe morta e "ripulire" tutti i riferimenti ad essa dalle firme dei metodi o dalle associazioni rimanenti sarebbe considerato pulizia o refactoring? Sono anche in forte disaccordo sul fatto che l'esecuzione di unit test sia facoltativa. Non hai idea di come le cose potrebbero rompersi. Ho visto cambiamenti nella stringa del messaggio di un codice di interruzione dell'eccezione perché qualcuno ha pensato che fosse una buona idea analizzarlo per agire su alcuni errori.

— Newtopiano,

Sono d'accordo con Newtopian, in particolare sul fatto di non dover ripetere i test. In effetti, dovrebbe esistere una suite di test automatizzata che viene eseguita non meno di una volta per commit. Indipendentemente dal fatto che si tratti di cleanup o refactoring , se si ha una modifica del codice da impegnare nel controllo della versione, i test dovrebbero essere eseguiti.

— Kojiro,

Dovresti sempre fare una build completa dopo aver fatto qualsiasi pulizia, anche se è solo uno spazio bianco e i commenti cambiano. Chiedi a tutti gli autori Python o Makefile di questo.

— JBR Wilkinson,

3

Il refactoring aggiunge conoscenza al tuo codice. Se sai che qualcosa ha un nome errato, gli dai un nome migliore. Se sai che qualcosa può essere fatto meglio, lo cambi in qualcosa di meglio.

Sono molti i passaggi, piccoli e grandi, che si spera possano portare a un programma migliore.

— user1249
fonte

3

Sono d'accordo con "refactoring è una parola elaborata per ripulire il tuo codice" ma non con "solo". Le persone usano parole fantasiose per una ragione: a volte perché vogliono apparire intelligenti, a volte perché stanno trasmettendo un significato più grande o più preciso, e il refactoring IMHO (anche se occasionalmente usato in modo improprio) si riferisce generalmente a quest'ultimo.

"Pulizia" potrebbe significare qualsiasi cosa da "riformattare un po '" a "riscrivere 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 corpus di buone pratiche sul tipo di cose che fai: alcune sono ad-hoc, ma ci sono principi generali, come l'uso di unit test, l'estrazione di parte delle funzioni in nuove funzioni o classi, ecc., Che le persone possono e dovrebbero imparare .

Dici "basta ingannare la gestione per allocare tempo per la pulizia del codice". Ma se dire "refactoring" trasmette correttamente il concetto che un investimento costante nella chiarezza pagherà i dividendi in efficienza in futuro, allora non è un "trucco", è una comunicazione chiara ed efficace.

— Jack V.
fonte

2

Il refactoring consiste nel codificare come la normalizzazione nei dati relazionali. È un processo di astrazione dei concetti in rappresentazioni più pulite, più chiare ed efficienti del loro ruolo nell'applicazione.

— sunwukung
fonte

1

È un modo interessante di vederlo. Forse viene dal mio background di database, ma c'è qualcosa che mi infastidisce per lo stress sul refactoring e mi hai aiutato a metterci il dito sopra. È che in un database ciò che non si risolve nella progettazione richiede 10 volte più tempo per essere risolto nei test e probabilmente 1000 volte più in produzione. Quindi un buon DBA è ansioso di sistemare le cose il prima possibile. La mia impressione è che troppo tempo il refactoring nelle fasi successive è indicativo di troppo poco tempo impiegato nella progettazione.

— user21007

@ user21007: il codice è molto più complicato di uno schema di database, ma molto più facile da modificare e distribuire.

— Kevin Cline il

1

Dipende da come intendi il termine refactoring. Per la maggior parte delle persone questo è un processo di miglioramento della struttura senza cambiare comportamento. Se sei d'accordo, allora sì, è stato fatto molto prima che questo libro venisse pubblicato. Lo so, perché stavo (tra le altre cose) rinominando le classi, estraendo le classi ed estraendo i metodi prima che il libro fosse scritto. Non lo chiamavo refactoring, ma in sostanza stavo facendo esattamente la stessa cosa.

Per me il refactoring personale è ciò che la gente ora chiama "refactoring di codice automatizzato", ovvero: supporto per varie tecniche di refactoring all'interno di un IDE. Questo è un vero miglioramento di quello che stavo facendo prima (che in effetti è stato molto doloroso). Posso effettuare una modifica in una classe e non preoccuparmi di come ciò influirà sul resto del software. Penso che Martin abbia formalizzato la tecnica di refactoring fino al punto in cui potrebbe essere rappresentato come algoritmo e quindi implementato in vari IDE là fuori.

Quindi, se capisci il refactoring come un processo, non è una novità. Se lo vedi come automazione, allora sì, è un enorme miglioramento. Prova a rinominare alcune classi principali (letteralmente, non attraverso le opzioni di refactoring del tuo IDE) in un progetto abbastanza grande per capire perché :)

— Jacek Prucia
fonte

0

Il refactoring è in effetti un "cleanup" del codice, ma anche una ristrutturazione del codice. Nella mia squadra il refactoring è di solito il secondo. Quando abbiamo un caso di "refactor", allocare tempo per ristrutturare il nostro codice, ad esempio per renderlo allineato con una nuova architettura o modello di informazione o per renderlo più efficiente.

Il codice "cleanup" è qualcosa che facciamo continuamente senza tempo appositamente assegnato per questo. Per me "ripulire" è di solito rinominare, ripulire i commenti, ecc.

— Mantisen
fonte

1

la ridenominazione è una tecnica di refactoring standard!

— Chuck Stephanski,

0

Direi di no

Potrebbe esserci una pulizia nel processo di refactoring ma non è essenziale.

La pulizia viene fornita presupponendo che il codice precedente non sia pulito. In realtà, gli sviluppatori riformattano il loro codice anche il codice originale è già pulito.

DRY è un fattore 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

— ohho
fonte

0

Pulire il tuo codice è come riordinare la tua casa, refactoring è come abbattere un muro e possibilmente metterlo da qualche altra parte

— Homde
fonte

0

Quando qualcun altro ripulisce la tua casa, non riesci a trovare nulla perché l'obiettivo è quello di rendere le cose pulite e fuori mano. Il refactoring costruirà ed etichetterà stanze, armadi, armadi, scaffali, bidoni, ecc. Conserva ancora la maggior parte delle stesse cose (puoi ancora fare un panino al formaggio grigliato in cucina e mangiarlo in salotto), ma dovrebbe farlo più facile da trovare e possibilmente avere luoghi efficienti per mettere nuove cose.

— Jeffo
fonte

Non sono un fanatico delle parole d'ordine, ma a volte compiti comuni devono essere etichettati e formalizzati in modo che tutti sappiano di cosa stai parlando. Un client segnala un bug e il gestore urla "Vai a pulire il tuo codice!" sai che non stanno parlando di refactoring.

— JeffO,

0

Il termine "refactoring" è elegantemente mutuato dall'algebra. Significa semplificare i termini per produrre lo stesso risultato. Non solo elegante, è stato rivoluzionario, ma ha richiesto un approccio rigoroso al codice, a un livello che ha sorpreso molti. E così il termine stesso è stato significativo e utile.

— Smandoli
fonte

-1

No. Il refactoring sta migliorando la struttura senza cambiare comportamento. Il refactoring in senso stretto implica una buona disciplina di prova. Ciò non è necessariamente necessario quando si "puliscono le cose".

— Willie Wheeler
fonte

2

atteggiamento pericoloso. Rimuovere un'intera porzione di codice morto e configurazione morta significa ripulire e cambiare la firma di un singolo metodo come refactor. Eppure in entrambi i casi vorrei ottenere una buona disciplina di prova per assicurarmi di non aver infranto nulla.

— Newtopiano,

Non sto dicendo che è un bene / sicuro / desiderabile apportare modifiche importanti senza disciplina di prova. Sto dicendo che il refactoring come metodologia implica una disciplina di prova, mentre "ripulire le cose" non è affatto una metodologia.

— Willie Wheeler,

Quindi, se capisco correttamente se non ha un nome di fantasia, allora siamo a posto !! : -O sto solo scherzando, vedo quello che stai cercando di dire, vero che ripulire le cose difficilmente potrebbe essere chiamato una metodologia ma poi non è nemmeno il refactoring. È solo una parolaccia che afferma che stai cambiando il codice senza alterarne il comportamento. Di per sé, non ha implicazioni sul test. Seguendo le buone pratiche di codifica si afferma che se il codice è cambiato, dovrebbe essere testato indipendentemente da come si chiama l'azione che ha generato la modifica.

— Newtopian,

1

Certo, posso comprarlo. La disciplina del test è più su come si esegue il refactoring, ma non è inerente alla definizione. (Vale a dire che posso refactificare il codice senza alcun test). Non so se posso essere d'accordo sul fatto che il refactoring non sia una metodologia - ci sono interi libri scritti con schemi passo-passo e così via.

— Willie Wheeler,

-1

I due si sovrappongono un po '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.

— PSU
fonte

-2

"Refactoring" è davvero la stessa cosa di "rearchitecture", ma con una connotazione più forte di "nessun cambiamento di funzionalità". È anche più chiaro in termini di obiettivo della ri-architettura, che spesso consiste nel "scomporre" il codice comune in blocchi riutilizzabili.

— DVK
fonte