Quando refactoring

31

Ho letto la maggior parte del libro di Refactoring di Fowler e ho rifatto il maggior numero di applicazioni nel mio passato, grandi e piccole.

Una delle cose più difficili che insegno è "quando" il refactoring. Tendo a farlo basandomi su una sensazione istintiva che mi ha servito molto bene in passato. Tuttavia, quando si entra in discussione con le persone sul fatto che un pezzo di codice debba essere lasciato solo o rifattorizzato in questo momento, è difficile sostenere il "controllo dell'intestino".

Credo che ci dovrebbero essere approcci più rigorosi a questo, ma non sono sicuro di quello che sono.

Capisco "odori di codice", refattore rosso-verde e altri pensieri, ma spesso sento che il momento migliore per il refactoring non è la prima volta che scrivi il codice, ma la seconda o terza volta che stai usando il codice codice e rendersi conto che in realtà è un problema ed è in uso.

    
posta Hortitude 19.02.2012 - 20:59
fonte

9 risposte

22

Refactor quando il costo del refactoring è inferiore al costo del refactoring non .

Misura il "costo", comunque puoi. Ad esempio, il codice è così mal implementato che bug insignificanti costano ore o giorni per essere riparati? Il refactoring ti consentirà di acquisire più clienti, aumentare la capacità o migliorare le prestazioni e rendere più felici i tuoi attuali clienti?

    
risposta data 20.02.2012 - 02:47
fonte
11

  1. La complessità ciclomatica della funzione sotto 5?
  2. Hai completamente compreso la complessità ciclomatica senza seguire quel collegamento?
  3. Hai un test automatizzato o un caso di test documentato per ogni percorso attraverso la funzione?
  4. Vengono trasferiti tutti i casi di test esistenti?
  5. Puoi spiegarmi la funzione e tutti i suoi casi limite in meno di 1 minuto?
  6. In caso negativo, che ne dici di 5 minuti?
  7. 10 minuti?
  8. Ci sono meno di 100 righe di codice nella funzione (compresi i commenti)?
  9. Riesci a trovare altri due sviluppatori che accettano che questo codice sia privo di errori solo tramite ispezione visiva?
  10. Questa funzione è utilizzata in un unico posto?
  11. La funzione soddisfa i suoi obiettivi di rendimento (Tempo / Memoria / CPU)?

Scoring

Aggiungi le risposte "no" sopra:

  • 0-1 - Perché dovresti pensare a refactoring di questo? Probabilmente vuoi semplicemente rinominare le variabili perché non ti piace la convenzione di denominazione dello sviluppatore precedente
  • 2-5 - Potrebbe essere necessario un piccolo ritocco, ma non terrei una versione di produzione per qualcosa in questo intervallo
  • 6-8 - OK, probabilmente dovremo risolvere questo problema ... Probabilmente continueremo a rivisitare questo e / o non sappiamo realmente cosa stia facendo. Ancora sul recinto, ma è altamente sospetto
  • 9+ - Questo è un ottimo candidato per il refactoring. (Nota, scrivere casi di test è una forma di refactoring)

link     
risposta data 16.05.2013 - 14:30
fonte
8

Quando il tuo istinto ti dice che probabilmente dovresti eseguire un refactoring, è probabile che sia il tuo istinto a dirti con un po 'di ritardo che hai messo qualcosa di importante troppo a lungo.

I understand "code-smells", red-green-refactor and other thoughts, but often I feel that the best time to refactor is not the first time you write the code, but the second or third time you are using the code and realize that it is actually a problem and is in actual use.

Ci sono effettivamente due livelli per il refactoring. Il primo è l'ovvio problema che appare quando si esegue il primo codice. Queste sono le piccole ottimizzazioni che ti costano molto poco da fare in anticipo. Cose come mantenere piccoli metodi e classi e aderire a DRY e SRP. Poi hai la fase aggiuntiva di gestire i principali difetti del tuo progetto, che potrebbero non essere immediatamente evidenti fino a quando il tuo codice non avrà un paio di miglia sotto di esso. Si tratta di questo secondo livello di cui si sta parlando e, tuttavia, per garantire che il successivo refactoring non sia troppo costoso, è necessario aver già scritto il codice in modo tale che lo sforzo che si prevede in seguito sia reso più facile e meno costoso, il che significa fare un refactoring anticipato.

Come Jeff ha detto nella sua risposta, "il tempo è denaro" , in particolare nelle aziende in cui il carico di lavoro è elevato e i rischi ancora più elevati. Il tempo trascorso in anticipo assicurandosi che il codice sia nel suo stato migliore possibile è il tempo risparmiato in seguito, quando prendere in giro ciò che avrebbe dovuto essere un semplice refactoring si rivela essere un'operazione importante.

Quando scrivi software, ogni momento dedicato a migliorare il tuo codice in anticipo viene salvato più tardi, quando ne avrai davvero bisogno. Quanto prima ti rifatti, più chiari saranno i tuoi successivi cambiamenti. È come fare un acconto in dollari di oggi contro il debito tecnico futuro che sarà in dollari gonfiati domani.

In ogni caso, il refactoring non dovrebbe essere un compito che rimanderai a qualche futuro misterioso quando il software è già completo e stabile, poiché aumenta i tuoi rischi più tardi quando la posta in gioco è molto più alta e il prodotto molto più difficile da modificare. Il refactoring dovrebbe essere una parte delle tue attività quotidiane, e questa è l'essenza della filosofia Red-Green-Refactor che hai menzionato.

    
risposta data 19.02.2012 - 21:31
fonte
2

Penso che la tua domanda possa essere risolta in modo diverso da ogni sviluppatore e persino dalla direzione responsabile della programmazione.

La mia preferenza personale è che, ogni volta che imparo qualcosa di nuovo o migliori le mie migliori pratiche, rifletto il codice che posso - mi piace mantenere il mio codice allo standard non appena apprendo quale sia lo standard migliore da usare per quello situazione era. Sono autorizzato a farlo anche perché è un'azienda più piccola che utilizza lo stesso software per lunghi periodi di tempo.

In una società di sviluppo software più grande dove il tempo è denaro, potrebbe essere solo iniziare a progettare con le migliori pratiche che hai imparato da questo punto in poi, non preoccuparti di refactoring fino alla versione 2 di quel software specifico?

Sento che insegnare quando refactoring dipende davvero dalla compagnia in cui ti trovi attualmente.

    
risposta data 19.02.2012 - 21:07
fonte
2

"When to refactor ?"

Risposta breve: ogni volta che incontri un codice che ha un cattivo odore o che potrebbe essere migliorato ( regola Boy Scout )

In pratica, questo succede:

  • Se pratichi TDD, sistematicamente durante la fase Refactor del ciclo TDD, ovvero, una volta che il test è verde e prima di iniziare a scrivere un nuovo test.
  • Come risultato di una revisione del codice
  • Quando si acquisisce il codice legacy
  • Quando si utilizza un codice che sembra progettato in modo scomodo
  • ecc.
risposta data 20.02.2012 - 16:42
fonte
1

Quando ho iniziato a studiare il refactoring, il mio mentore mi ha detto: "Fallo due volte, tieni il naso, fallo tre volte. (Grazie, Josh!) Per essere precisi, quello che stava dicendo è che quando stai per scrivere lo stesso blocco di codice per la terza volta (o anche uno schema di codice simile), questo è il momento del refactoring. L'ho seguito negli ultimi 10 anni, e ho trovato che fosse una regola empirica abbastanza valida.

L'uso di Eclipse, o IDE simile che ha un strong supporto per il refactoring, riduce lo sforzo per eseguire il refactoring. Il supporto IDE rende più probabile il refactoring non appena si preme la "terza volta" (o si vede la necessità), invece di vederlo come uno sforzo aggiuntivo.

Inoltre, anche TDD è di grande aiuto, dal momento che puoi continuare a eseguire i test come refactoring e sapere che non hai rotto nulla.

    
risposta data 19.02.2012 - 22:22
fonte
1

Il refactoring in base alla sua definizione è un processo. Ciò implica che non dovresti cercare di trovare tempo libero per svolgere l'attività di rafactoring, ma dovresti continuare a rifattorizzare tutto il tempo in cui ti imbatti in codice che potrebbe essere scritto meglio.

Personalmente mi piace scrivere prototipi evolutivi, dicendo più semplicemente: codice che funziona e poi refactoring quelli fino a che non soddisfano gli standard di codifica previsti. Un altro buon esempio è l'aggiunta di funzionalità aggiuntive e il refactoring del codice esistente per consentirne il riutilizzo.

    
risposta data 19.02.2012 - 23:18
fonte
1

Nei miei 20 anni di programmazione, ecco l'unica regola empirica in cui ho effettivamente visto il lavoro, a cui le persone possono attenersi e ai manager è concesso tempo. (Il refactoring è come una dieta: certo, "calorie in / calorie" è la formula per perdere peso, ma questo non si traduce in una dieta a cui le persone si adegueranno.) E così:

Refactor continuamente, mentre lavori. Utilizza lo sviluppo basato su test in modo da avere diversi cicli rosso-verde-refactor nel corso della giornata. Riforma solo le parti del codice che hai toccato.

Una volta che sei più sicuro di te stesso, puoi variare da questo regime.

    
risposta data 11.12.2014 - 23:15
fonte
1

Penso che ciò dipenda dalle esigenze del proprietario del progetto e dal ragazzo che risponde alla qualità del codice. Semplicemente non puoi decidere da solo, quando i soldi di qualcun altro sono in discussione.

Per motivi tecnici, ce ne sono diversi.

  • Se hai un bug nel codice, significa che questo posto è frainteso ed è MOLTO probabile che più errori potrebbero essere nascosti qui e sicuramente ci saranno grandi problemi con qualsiasi tentativo di sviluppare le parti di codice connesse. Quindi, questo posto dovrebbe essere controllato per il possibile refactoring.
  • Un altro motivo è quando aggiungi o modifichi una funzionalità e il vecchio codice è molto scomodo per la modifica / aggiunta e le modifiche / aggiunte successive sono altamente possibili. Certo, dovresti bilanciare il costo.
  • Forse il motivo più serio è quando si sta modificando il codice e non è possibile testarlo.
risposta data 19.02.2012 - 22:44
fonte

Leggi altre domande sui tag