A che punto il refactoring non vale la pena?

StackOverflow https://stackoverflow.com/questions/615614

Domanda

Supponi di avere un programma che attualmente funziona come dovrebbe. L'applicazione ha un codice molto scarso dietro, consuma molta memoria, non è scalabile e richiederebbe una grande riscrittura per implementare eventuali cambiamenti di funzionalità.

A che punto il refactoring diventa meno logico di una ricostruzione totale?

È stato utile?

Soluzione

Joel ha scritto un bel saggio su questo argomento:

Cose che non dovresti mai fare, Parte 1

La lezione chiave che ne ho tratto è che sebbene il vecchio codice sia orribile, fa male ai tuoi occhi e al tuo senso estetico, c'è una buona probabilità che gran parte di quel codice stia correggendo errori e problemi non documentati. Vale a dire, ha un sacco di conoscenza del dominio incorporato e sarà difficile o impossibile replicarlo. Ti batterai costantemente contro i bug di omissione.

Un libro che ho trovato immensamente utile è Lavorare in modo efficace con il codice precedente di Michael C. Piume. Offre strategie e metodi per avvicinarsi anche a codici legacy davvero brutti.

Altri suggerimenti

Uno dei vantaggi del refactoring rispetto alla ricostruzione è che se è possibile eseguire il refactoring passo dopo passo, ovvero in incrementi, è possibile testare gli incrementi nel contesto dell'intero sistema, rendendo più rapidi lo sviluppo e il debug.

Il codice vecchio e distribuito, anche se brutto e lento, ha il vantaggio di essere stato testato a fondo e questo vantaggio si perde se si inizia da zero.

Un approccio di refactoring incrementale aiuta anche a garantire che sia sempre disponibile un prodotto che può essere spedito (e che migliora costantemente).

C'è un bell'articolo sul web su come Netscape 6 è stato scritto da zero ed è stato dal punto di vista commerciale una cattiva idea .

Bene, la risposta più semplice è se ci vorrà più tempo per il refactoring di quanto non lo sarà per ricostruire, quindi dovresti semplicemente ricostruire.

Se si tratta di un progetto personale, ti consigliamo di ricostruirlo comunque, poiché probabilmente imparerai di più dalla costruzione da zero di quanto non faccia dal refactoring, e questo è un grande obiettivo dei progetti personali.

Tuttavia, in un ambiente professionale a tempo limitato, dovresti sempre andare con tutto ciò che costa all'azienda la minor quantità di denaro (per lo stesso payoff) a lungo termine, il che significa che scegliere quale richiede meno tempo.

Certo, può essere un po 'più complicato di così. Se altre persone possono lavorare su funzionalità mentre è in corso il refactoring, questa potrebbe essere una scelta migliore rispetto al fatto che tutti aspettino che venga creata una versione completamente nuova. In tal caso, la ricostruzione potrebbe richiedere meno tempo rispetto a solo il refactoring avrebbe richiesto, ma è necessario tenere conto dell'intero progetto e di tutti i collaboratori del progetto.

Quando dedichi più tempo al refactoring che alla scrittura effettiva del codice.

Nel punto in cui il software non fa quello che dovrebbe fare. Il refactoring (modifica del codice senza modificare la funzionalità) ha senso se e solo se la funzionalità è "come previsto".

Se puoi permetterti il ??tempo di ricostruire completamente l'app, non è necessario migliorare la funzionalità in modo incrementale e non desideri conservare nessuno dei codici esistenti, la riscrittura è sicuramente un'alternativa praticabile. D'altra parte, è possibile utilizzare il refactoring per eseguire una riscrittura incrementale sostituendo lentamente le funzioni esistenti con funzioni equivalenti che sono meglio scritte e più efficienti.

Se l'applicazione è molto piccola, è possibile riscriverla da zero. Se l'applicazione è grande, non farlo mai. Riscriverlo progressivamente, un passo alla volta confermando che non hai rotto nulla.

L'applicazione è la specifica. Se la riscrivi da zero, molto probabilmente ti imbatterai in molti bug insidiosi perché "nessuno sapeva che la chiamata a questa funzione avrebbe dovuto restituire 3 in quel caso molto specifico". (comportamento non documentato ...).

È sempre più divertente riscrivere da zero in modo che il tuo cervello possa indurti a pensare che sia la scelta giusta. Fai attenzione, molto probabilmente no.

Ho lavorato con tali applicazioni in passato. L'approccio migliore che ho trovato è graduale: quando lavori sul codice, trova le cose che vengono fatte più volte, raggruppandole in funzioni. Tieni un quaderno (sai, uno vero, con carta e una matita o una penna) in modo da poter segnare i tuoi progressi. Usalo in combinazione con il tuo VCS, non al suo posto. Il notebook può essere utilizzato per fornire una panoramica delle nuove funzioni create come parte del refactoring e il VCS ovviamente riempie gli spazi vuoti per i dettagli.

Nel tempo, avrai consolidato molto codice in posizioni più appropriate. La duplicazione del codice durante questo periodo di tempo sarà quasi impossibile, quindi fallo nel miglior modo possibile fino a quando non hai raggiunto un punto in cui puoi davvero avviare il processo di refactoring, verificando l'intero base di codice e lavorarci su nel suo insieme.

Se non hai abbastanza tempo per quel processo (che richiederà molto tempo), probabilmente riscrivere da zero usando un approccio test-first è meglio.

Lo zio Bob pesa in con il seguente:

  

Quando una riprogettazione è la strategia giusta?

     

Sono felice che tu abbia posto questa domanda. Ecco la risposta Mai.

     

Guarda, hai fatto il casino, ora pulisci.

Un'opzione sarebbe quella di scrivere test unitari per coprire l'applicazione esistente e quindi iniziare a refactact bit per bit, usando i test unitari per assicurarsi che tutto funzioni come prima.

In un mondo ideale avresti già avuto unit test per il programma, ma dati i tuoi commenti sulla qualità dell'app suppongo che tu non ...

Nessun documento, nessuno scrittore originale, nessun caso di test e un sacco di bug rimanenti.

Non ho avuto molta fortuna con piccole modifiche incrementali quando il codice che eredito è davvero male. In teoria il piccolo approccio incrementale suona bene, ma in pratica tutto ciò che ne risulta è un'applicazione migliore, ma ancora mal progettata che tutti pensano sia ora IL TUO design. Quando le cose si rompono, le persone non pensano più che sia a causa del codice precedente, ora diventa la TUA colpa. Quindi, non userei la parola riprogettazione, refactoring o qualsiasi altra cosa che implichi un tipo di manager che stai cambiando le cose a modo tuo a meno che non lo farei davvero a modo mio. Altrimenti, anche se potresti aver risolto dozzine di problemi, tutti i problemi che ancora esistevano (ma non erano stati scoperti) verranno ora attribuiti alla tua rielaborazione. E assicurati che se il codice è errato, le tue correzioni scopriranno molti più bug che sono stati semplicemente ignorati prima perché il codice era così male all'inizio.

Se sapessi davvero come sviluppare sistemi software, farei una riprogettazione dell'intero sistema. Se non sai VERAMENTE come progettare un buon software, allora direi di attenersi alle piccole modifiche incrementali, altrimenti potresti finire con una base di codice altrettanto cattiva dell'originale.

Un errore che viene spesso commesso durante la riprogettazione è che le persone ignorano la base di codice originale. Tuttavia, riprogettare non deve significare ignorare totalmente il vecchio codice. Il vecchio codice doveva ancora fare ciò che deve fare il tuo nuovo codice, quindi in molti casi i passaggi necessari sono già nel vecchio codice. Copia e incolla quindi modifica le meraviglie quando riprogetta i sistemi. Ho scoperto che in molti casi, riprogettare e riscrivere un'applicazione e rubare frammenti dal codice originale è molto più rapido e molto più affidabile di piccole modifiche incrementali.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top