La riscrittura del vecchio codice è ancora una buona idea? [duplicare]

Question

La riscrittura del vecchio codice è ancora una buona idea? [duplicare]

#1 da (2 voti)
#2 da (1 voti)
#3 da (1 voti)

0

Diciamo che ho un grande, meraviglioso set di test di integrazione per il mio prodotto. Verifica tutto e tutto ciò che dobbiamo testare. E dopo che il prodotto ha superato tutti questi test, diamo un'occhiata all'origine, decidiamo che è completa, e ricominciamo da capo. È una buona decisione commerciale?

Riconosco pienamente che nessun set di test di integrazione è perfetto, e ci sono sempre limiti di tempo / budget da prendere in considerazione, ma per il gusto di questa domanda li metteremo da parte. Diamo un'occhiata ai vantaggi.

Se la nostra base di codice è di 5 anni e scritta dai primi programmatori della società che stavano imparando mentre andavano, e ora abbiamo programmatori "esperti" che possono rendere il codice più gestibile. Sì, alcuni potrebbero aver bisogno di tempo di accelerazione nella conoscenza del dominio, ma direi che scrivere da zero aiuterebbe a sviluppare questa conoscenza più velocemente e più completamente.
Se la versione esistente del nostro codice utilizza una libreria di base che è "obsoleta" e si comporta male in tutti gli scenari, e la sua sostituzione all'ingrosso richiederà 10 mesi e la riscrittura con la nuova cosa brillante richiederà 6. Sembra come un gioco da ragazzi, giusto?

Ci sono molti altri "buoni" motivi per riscrivere un prodotto, ma il punto di Joel è che sei destinato a commettere gli stessi errori che il prodotto precedente aveva già superato.

Ma che dire dei test? Se ho un modo di testare un prodotto che non è legato al codice stesso (ad esempio, test di integrazione), non garantisce che quei potenziali errori vengano scoperti presto?

Supponendo che tu abbia un modo di verificare il comportamento e l'output facilmente, specialmente con gli strumenti disponibili oggi, partire da zero è ancora una cattiva idea?

design architecture rewrite

posta wtfsven 03.06.2017 - 09:19

fonte

3 risposte

Leggi altre domande sui tag design architecture rewrite

Dove mettere il comportamento di DTO? Codice pulito struttura oggetto vs dati CQS indica una classe per una query nei comandi?

score 2 · Answer 1

Dipende dal tuo problema con il codice. Se non lo si visita quasi mai, probabilmente non ne vale la pena. Se ti ritrovi a fare il debug tutto il tempo, spendendo il 99% a capire come funziona e l'1% a cambiare il codice, potrebbe valerne la pena.

E poi potresti avere alcune persone cresciute con il caos che non vedono il problema (loro conoscono tutte le stranezze perché le hanno create o erano vicine quando sono emerse). Hanno anche una buona memoria in modo che conoscano il loro modo in quello che hanno fatto. Buona fortuna con loro.

score 1 · Answer 2

Non esiste una risposta unica per questa domanda, si depaend sul caso. Riscrivere il tuo codice ti costerà del tempo, e ti sentirai come se non avessi ricevuto nulla per questa volta. Ma se pensi al futuro, se un giorno vorresti cambiare le cose nel tuo codice o aggiungere funzionalità ci vorrà molto più tempo con un codice cattivo, sarà difficile eseguire il debug, quindi potrebbe essere che riscrivere il codice ti farà risparmiare tempo a lungo termine. Ti consiglierei di farlo se pensi che ci siano buone probabilità di cambiare questo codice in futuro, e se non lo fai riscrivi. Prova a pensare a quanto tempo dovrai spendere per la riscrittura e quanto tempo ci vorrà per aggiungere funzionalità al codice corrente. Ti aiuterà a decidere.

score 1 · Answer 3

Il pericolo qui viene sedotto dal campo verde.

Tutti amiamo la sensazione di un nuovo progetto in cui aggiungere cose è così facile da essere quasi senza pensieri. Una volta che il tempo è finito, è molto allettante voler tornare indietro.

Un codice base stabilito ti rallenta. Devi fare ciò che desideri in base a ciò che già esiste.

Puoi solo recuperare la velocità ignorando queste considerazioni perché è questa la velocità, considerazioni ignorate. Potresti andare veloce prima perché non sapevi nemmeno che li stavi ignorando.

Un codice base ti insegna cose che devono essere considerate. Se il tuo è come la maggior parte dei progetti, il codice è dove si trova la tua documentazione delle specifiche reali.

Potresti pensare che sia semplicemente una limitazione fisica del lavoro nel codice base. So che non è vero perché quando ho lavorato per convertire una base di codice da una lingua all'altra mi sento ancora rallentato anche quando la nuova lingua è ancora appena iniziata.

Questo perché anche se ho tutto questo spazio fresco in cui lavorare posso ancora vedere cosa sta arrivando. Quindi sto attento a dove metto le cose.

Ora dato tutto ciò che potresti sentire un po 'intrappolato. Vi assicuro, non esiste una base di codici così pienamente stabilita che una decisione negativa di progettazione diffusa all'interno di essa non possa essere rovesciata con un lavoro deliberato. È possibile recuperare il lavoro utile che è stato messo dentro senza perpetuare le cattive idee. Le modifiche incrementali apportate per migliorare il codice e l'aggiunta di test aiutano a farlo lentamente. Se hai bisogno di un grande cambiamento improvviso ci vorrà un po 'di codice eroico. Anche se ci provi, non limitarti a una riscrittura completa. Affronta una cattiva idea alla volta.

Altrimenti, se ti limiti alla riscrittura completa, quando hai finito scoprirai dopo tutto quel lavoro che hai semplicemente rimpiazzato vecchie cattive idee con nuove cattive idee.

Non lasciarti sedurre dal lato verde.