Gran parte di un framework legacy (interrotto) da conservare [duplicato]

È bello averlo chiesto prima di iniziare.

Secondo Joel Spolsky (uno sviluppatore di software esperto e rispettato, nonché uno degli addetti allo scambio di stack), il numero uno "più grande errore strategico" che un'azienda può fare è decidere di re- scrivi il codice da zero .

In quel post del blog, Joel sottolinea che è molto più divertente scrivere il proprio codice piuttosto che cercare di capire un codice esistente, quindi i programmatori hanno un pregiudizio verso la scrittura dei propri sistemi invece del ri-factoring. Il problema con questo è che le basi di codice esistenti hanno un sacco di "conoscenze" di built-in. Il codice esistente tratta quasi certamente molti piccoli dettagli / dettagli che sono assolutamente fondamentali per rendere il software effettivamente utile. Quando butti via un sistema legacy, butti via tutta questa conoscenza. Sostituirlo è probabilmente più difficile e richiede più tempo di quanto immagini.

Sono caduto personalmente in questa trappola. Ho completamente riscritto un complesso sistema legacy per gli stessi motivi che hai citato (molti bug, codice confuso, mancante di alcune funzionalità). Una volta riavviato il sistema, ho dovuto rimediare a un sacco di problemi che erano già stati risolti nel sistema originale. Le persone non tecniche che hanno utilizzato il software non hanno visto il mio "codice pulito": hanno appena visto un nuovo sistema che ha avuto piccoli problemi che erano già stati (dolorosamente) risolti. In retrospettiva, avrei dovuto re-fattorizzare non riscritto.

Se il codice è bacato - correggi i bug. Se il codice è disorganizzato, organizzalo. Ma non buttare via tutto.

Il tuo piano di chucking System A e riscrittura basato su System B può funzionare, ma solo se sono soddisfatte alcune condizioni:

• Il sistema B deve già fornire una parte significativa della funzionalità del sistema A. Altrimenti, stai solo riscrivendo da zero e le precauzioni in si applicano le risposte di @ akh2103 .
• L'architettura di System B si presta bene ad aggiungere estensioni al sistema. Se questo non è il tuo caso, provare ad aggiungere la funzionalità aggiuntiva richiesta dal sistema A per creare un groviglio altrettanto grande di quello attuale.
• L'eccesso di funzionalità di System B (ma il sistema A non ha bisogno) e la nuova funzionalità non interferiscono tra loro, o sono possibili più installazioni con sottoinsiemi della funzionalità generale per il sistema B + aggiornato.

Se queste condizioni sono soddisfatte, può funzionare per migrare verso un sistema che incorpora sia il Sistema A corrente che il Sistema B. corrente. In tal modo, proverei a usare il più possibile il ciclo 'copia-rifattore' aggiungendo la funzionalità di Sistema A al nuovo sistema, invece di riscrivere tutte le nuove funzionalità da zero.

Quello che stai facendo è considerare le opzioni di a) Effettuare l'aggiornamento a "Sistema B" o b), mantenendo il "Sistema A".

Non possiamo darti una risposta diretta - molte variabili. Il più significativo di solito è il meno tecnico, e richiede una consultazione significativa con i tuoi manager e controllori finanziari. Supponendo che A sia distribuito e per lo più funzionante, il costo di rimanere su A è un investimento iniziale basso con costi elevati. Il vantaggio di B - i costi correnti inferiori, è compensato da un costo iniziale (solitamente non insignificante).

In questo contesto, il costo include tutte le cose che un'impresa considera: dollari, costo opportunità, rischio e implicazioni fiscali (A potrebbe essere la manutenzione, B, tutte capitalizzate ai fini fiscali).

In questo puoi e dovresti inserire cose "soft" come "Nessuno vuole lavorare su un vecchio codice crufty" e "È facile reclutare sviluppatori per lavorare sulle nuove cose brillanti", così come " Non importa cosa facciamo, A sarà sempre bacato, ma abbiamo una scelta con B e make è bacato come ti piace "

Quello che dovresti fare per valutarli è mettere insieme un piano per entrambe le opzioni, delineando i relativi costi (Tempo, Soldi, Rischio ...) e i vantaggi di ciascuna opzione, e prendere la decisione sugli spot .

prima di scegliere "Sistema B" Leggi la risposta di @ akh2103 e leggi "Secondo effetto di sistema"

Sono assolutamente d'accordo con il consiglio di akh2103 contro la riscrittura da zero. Puoi riscriverne pezzi isolati (se possibile), ma non il sistema completo. Perché?

Dalla mia esperienza, solo il codice contiene la conoscenza dei casi aziendali sottostanti. Anche se chiedessi a tutti i ragazzi non tecnici che lavorano con la tua applicazione legacy, non otterresti tutti i requisiti e il tuo sistema riscritto inizialmente non riuscirebbe a soddisfare le reali richieste. E poi devi iniziare a ripararlo ...

Sebbene non ci sia un proiettile d'argento in quella situazione, penso che ci siano alcune linee guida:

• Assicurati di avere test automatici prima di iniziare il refactoring. È molto probabile che il tuo sistema legacy non ne abbia. Scrivere test per sistemi legacy può essere piuttosto complicato, tuttavia, poiché le dipendenze sono spesso cablate.
• Mantieni attivo il tuo codice legacy, ma ogni volta che è possibile cerca di implementare le nuove funzionalità separatamente (ad es. aggiungi nuovi servizi). L'idea è che nel tempo, la tua base di codice attiva si allontani lentamente dal sistema legacy. Martin Fowler lo chiama Applicazione Strangler .
• Riforma solo pezzi di codice più grandi se hai un motivo per toccarlo. La ragione può essere piuttosto piccola, ad es. cambiare un testo che viene visualizzato. Ma non iniziare a riscrivere un componente che funziona perfettamente senza essere stato modificato negli ultimi 6 mesi, solo perché il suo codice sembra brutto. Concentrati sul codice che devi modificare di più perché queste sono anche le parti che ti infastidiranno di più.