Quando ricostruisci un'applicazione o continui a correggere quella esistente [duplicato]

È una chiamata difficile.

Riferimento Joel obbligatorio: Cose che non dovresti mai fare, parte I

Detto questo, ci sono naturalmente dei casi in cui è ancora meglio riscrivere da zero piuttosto che continuare a riparare fondamentalmente a pezzi. Se al tuo caso si applicano tutte le seguenti condizioni, probabilmente hai un motivo per riscrivere da zero :

• ci sono nessun test automatico ,
• il team di progetto originale è scomparso e nessuno conosce il modo in cui il prodotto è implementato, pertanto eventuali modifiche sono incredibilmente difficili e i risultati sono imprevedibili,
• il prodotto è così di bassa qualità che sostituendolo con un'implementazione nuova, necessariamente complessa, non farebbe una grande differenza,
• la tecnologia utilizzata è obsoleta e c'è una pressante necessità di sostituirla con qualcosa di nuovo (ad esempio per abilitare alcune funzionalità principali desiderate o per distribuirle su una nuova piattaforma - @Thorbjörn's answer contiene un buon esempio per quest'ultimo).

(Se solo alcuni di questi si applicano ... beh, è quello difficile da decidere, e non c'è una risposta generale lì.) Ad ogni modo, avresti anche bisogno delle seguenti condizioni per darti almeno una possibilità di fare una tale mossa con successo:

• Il time-to-market non è un problema - i clienti sono abbastanza pazienti da aspettare un tempo improduttivo per una versione promessa, fondamentalmente migliore e non ci sono concorrenti,
• esiste una conoscenza live e dettagliata (idealmente in specifiche ben scritte, ma anche nelle teste di molte persone - e queste persone sono accessibili per rispondere alle domande degli sviluppatori) su come questa dannata cosa dovrebbe comportarsi in una situazione specifica,
• la gestione è almeno aperta all'idea e idealmente capiscono i potenziali costi e benefici

Tutto sommato, devi tener conto che una riscrittura completa da zero richiederà un lotto più tempo, impegno e dolore del previsto . Quindi, se puoi, prova a suddividere il lavoro in blocchi più piccoli, in sostituire solo i moduli / componenti del vecchio codice uno per uno . In questo modo

• puoi iniziare creando una serie di test di regressione attorno al programma esistente, il che rende molto più facile conservare (e se necessario, migliorare) la vecchia funzionalità con il nuovo codice,
• la maggior parte delle volte avrai un programma funzionante e aggiornato (quindi utenti e gestione più felici),
• puoi salvare parti di riscrittura (potenzialmente significative) del codice che non devono essere modificate e "funzionano".

How do you decide when it is time to rebuild a system with newer technology, versus keeping on plugging holes in an old one?

Con le imprese, di solito si riduce al denaro. Il loro scopo è fare soldi, e tendono a pensare in termini di esso. Se ha più senso, dal punto di vista finanziario, fare una riscrittura, allora è una strong indicazione che dovresti andare avanti (e, si spera, che tu abbia preso in considerazione molti lati diversi dell'equazione).

Attenzione però, come molti altri hanno sottolineato, gli sviluppatori tendono a sottovalutare pesantemente. Inoltre, di solito non è così semplice come "costerà X riscrivere, Y per correggere, e X < Y"; potrebbe essere necessario pensare in termini di licenze, rischio di una nuova implementazione, rischio della vecchia implementazione, opportunità commerciali mancate (tutte queste possono essere espresse in termini di denaro), documentazione, formazione e molto altro. Quel che sembra una buona idea, un minuto potrebbe non sembrare così bello se fai un passo indietro e ci pensi per un secondo.

And how do you make a case for rebuilding? How can you persuade the powers-that-be it is necessary to rebuild the system?

Questo segue piuttosto semplicemente da quanto sopra - si fa un caso mostrando una differenza stimata di costo tra le due soluzioni, nel tempo. Sì, ti stai decisamente tirando indietro quando lo fai, ma se hai intenzione di formulare raccomandazioni che hanno un grande impatto finanziario, non dovresti farlo alla leggera.

Una buona soluzione per richiedere una riscrittura è quando la tecnologia di implementazione non è più supportata.

Recentemente ho avuto l'esperienza che Windows 7 (64 bit) ha esplicitamente dichiarato che non è piaciuto il CD di installazione di Visual Basic 6 quando inserito. Abbiamo usato questo come un strong suggerimento che era giunto il momento di trasferire le nostre applicazioni VB6 (a Java in quanto è ciò che facciamo).

Qualcuno ha commentato Premature optimization is the root of all evil su una delle domande che aveva posto. Non puoi mai costruire una soluzione completamente ottimale per un problema. Certamente, correggere il codice di qualcun altro è uno dei compiti più frustranti quando si potrebbe avere un codice migliore.

Ma con riferimento a questo, se ti trovi changing the source code too often , forse devi smettere di tacere. :) Se sei l'unico a mantenerla e se technology is completely outdated , se newer (and better) alternatives are available , se holes are too much , potresti parlare molto bene alle tue autorità superiori. Non vedo alcun motivo per continuare a collegare i buchi quando puoi ricostruire lo stesso.

Riscrivere un'applicazione ad un certo punto è una decisione necessaria. Lasciare codice scaduto può significare incubo per manutenzioni - per correggere bug e aggiungere nuove funzionalità. Un'applicazione non finisce mai per fare solo ciò che è stato originariamente progettato e l'ambiente che è stato progettato non rimane mai lo stesso.

La vera domanda è "Come riscriverlo?"

Se l'applicazione originale è stata scritta in modo veramente modulare, può essere riscritta in più fasi.

Se non lo fosse (come accade spesso con i sistemi legacy), lo sviluppo deve essere ramificato, se un ramo continua a lottare con l'aggiornamento dei vecchi sistemi e un altro ne crea uno nuovo. Ciò richiede più investimenti, ma mantiene la società in vita senza lasciarsi alle spalle. La soluzione ottimale è provare e sviluppare componenti per la nuova applicazione che con qualche sforzo possono essere integrati nel vecchio, in modo che il nuovo sviluppo contribuisca in qualche modo al vecchio sistema.

Alcune linee guida per prevenire il raggiungimento di una situazione erano che l'intera applicazione deve essere riscritta senza alcuna possibilità di integrare un nuovo codice all'interno di essa:

Progetta e scrivi un codice modulare, usa l'iniezione delle dipendenze.

Rifatta il tuo codice spesso, non scrivere sul posto di lavoro.

Utilizza standard di codifica chiari, fornisci nomi validi in inglese corretto, non utilizzare la notazione ungherese.

Scrivi documentazione esterna e documentazione interna, non generarla automaticamente.

Non posso sottolineare abbastanza l'importanza di test unitari completamente automatizzati, test di integrazione, & test di sistema per consentire l'aggiornamento di entrambi i moduli esistenti e l'aggiornamento futuro di nuovi moduli.

L'approccio corretto e più sicuro consiste nell'isolare le tue modifiche.

In primo luogo, determinare dove deve essere effettuata la nuova correzione. Scrivi test intorno a questa funzionalità. Interrompere questa funzionalità in una nuova applicazione nella lingua / framework più recente.

Sì, hai un sistema diviso. Ma hai corretto il sistema, ripulito una piccola parte. Modularizza il tuo sistema. E ha aggiunto test per garantire che la correzione sia corretta.

Eventuali correzioni di bug / funzionalità verranno gestite allo stesso modo. Alla fine, l'app originale è sparita. Lasciando un bel nuovo sistema pulito, pieno di test.

Quando arriva a un punto in cui le correzioni che stai facendo ripetutamente richiedono tanto tempo quanto la riprogettazione del programma, puoi iniziare a pensarci. Ovviamente devi calcolare il tempo per il test / Q & A, ma se pensi che stia diventando una perdita di tempo allora è sicuramente utile considerarlo.

Quando l'intera architettura di base, la struttura o il fondotinta sono incompatibili con i nuovi requisiti aziendali.

IMHO, i cambiamenti principali sono gli unici quando inizi da zero. E aspettati che siano costosi.