Come devo fare per "revisionare" una grande applicazione legacy? [duplicare]

Non suggerirei di eseguire una riscrittura di un'intera applicazione. Soprattutto quello che viene attualmente utilizzato dal cliente. Non taglierai mai al nuovo sistema finché non potrà fare tutto ciò che fa il vecchio sistema. Mentre stai scrivendo il nuovo sistema, il cliente e il management stanno diventando impazienti e vogliono quelle nuove funzionalità. Tu o qualcun altro dovrai aggiungerli alla vecchia app, il che ti toglie tempo dalla nuova app, e accumulerai solo più lavoro che devi fare prima che sia completato. Le possibilità che tu abbia effettivamente completato il progetto diminuiscono col passare del tempo, finché non ti senti come se fossi in un progetto senza fine e le iniziazioni morali di andare giù.

In generale, una cattiva idea. Come link di MichaelT sopra riportato.

Quindi cosa fare invece?

Fai un bel sondaggio sulla base del codice corrente. Trova il buono, il brutto, il brutto e il giusto terrificante. Scopri cosa può essere pulito rapidamente, cosa può essere riutilizzato e refactored, cosa non è più utilizzato o necessario e cosa serve una riscrittura.

Progetta e implementa il tuo nuovo DAL. Guarda le pagine e il codice e distruggilo in modo da avere un livello aziendale separato che chiama DAL. Concentrati su pagine simili alla volta. Rilasciare mentre sono puliti e pronti. Rendilo più iterativo. Potrebbe essere necessario eseguire queste pagine più volte, ma assicurati di lasciarle ogni volta di più.

Quando viene introdotta una nuova funzionalità, b / c otterrai più di quello che è attualmente nella tua pipe line, incorporandole nello sforzo di pulizia. Quando rilasci una nuova funzione, rilascia il nuovo codice ripulito allo stesso tempo.

Ci vorrà del tempo? Sì. Si lo farà. Sono stato con la mia attuale compagnia da 3 anni e l'applicazione web client che ho ripulito non è stata completata. Ma abbiamo avuto numerose pubblicazioni importanti e l'abbiamo venduta a molti clienti diversi. Ora funziona su più piattaforme e diventa sempre più facile creare nuove pagine e funzioni. Se avessimo deciso di iniziare da zero e di rilasciare una volta terminato, beh, è ancora un lavoro in corso, e non avremmo maggiori versioni o clienti da mostrare per questo.

How much business logic is hiding in this application? Do you have the full specs at the start? All the requirements changes over the past decade? All the bugs that have been fixed? All the bugs that are still open? Comprehensive regression testing suite?

A cui è stata data risposta ...

How bad does the design have to be to justify a rewrite? This design is pretty bad. There is tons of business logic hiding in the application. No specs, no logs of requirements changes, no list of bug fixes, no list of open bugs, no test suite, no documentation. And the guy who originally wrote it is now in upper management.

Hai un'applicazione vecchia di dieci anni, senza documentazione su cosa dovrebbe realmente fare, su cosa è stato fatto per risolverlo o su cosa non sta facendo correttamente.

Ci sono due approcci.

Il primo è quello di riscriverlo lentamente dall'interno. Entrare, trovare un modulo, capire esattamente cosa fa e cosa dovrebbe fare e sostituirlo. Questo è un processo graduale. È probabilmente l'approccio migliore. Non è qualcosa a cui tende a piacere il management (ho scoperto che la gestione tende ad apprezzare grandi progetti che sembrano grandi e hanno grandi rilasci). Sostituire qualcosa dall'interno che non sembra che stia facendo qualcosa non ottiene riconoscimenti.

L'altro approccio è quello di andare e buttare via l'originale e ricominciare da capo. La domanda è "quanto tempo ci vorrà?" è una delle prime domande che viene posta. Per questo, si può ottenere una stima ragionevole

Se non ci sono documentazioni, una completa riscrittura, in questo modo scopri quante righe di codice ha l'applicazione e gettale nel COCOMO II modello. Questo presuppone che ci vorranno più linee di codice per scrivere il nuovo codice così come esiste adesso. Guarda quanto è grande.

La questione di questa è una buona idea per il business da intraprendere non è quella che i programmatori dovremmo fare. Abbiamo opinioni su di esso, e potremmo pensare che questa sia una terribile perdita di tempo o che sia qualcosa che sarebbe molto divertente da fare (consiglio vivamente di leggere Death March per avere un po 'di prospettiva su questo), ma non siamo noi a fare le chiamate per il business.

Identifica il lasso di tempo che questo richiederà e lascia che l'azienda decida se esiste un ritorno sull'investimento giustificabile.

Ricorda, c'è una terza opzione: lasciala com'è.

Has anyone done this successfully?

Ecco la storia di successo della nostra azienda. Per un bel po 'di tempo abbiamo avuto un sito web disordinato:

• PHP / MySQL, per lo più Drupal 6.
• Molti moduli Drupal personalizzati di media qualità.
• Alcune parti di codice legacy molto vecchie scritte in semplice PHP + SQL + HTML + JS + CSS (c'erano effettivamente file contenenti tutti quelli in una volta). Quelle erano in realtà parti molto importanti che provenivano da una versione precedente dell'applicazione.
• Due database interni MySQL (uno per Drupal e uno per le cose più vecchie), due database SQL Server esterni a cui è stata integrata la nostra app (tutti con solo query dirette).
• Nessuna specifica, nessun test, nemmeno nessun repository (ce l'abbiamo fatta in seguito).
• Ora non posso dire la dimensione della base di codice, ma c'erano circa 12 moduli personalizzati e circa 10 moduli Drupal personalizzati. Molte funzionalità sono state implementate solo con moduli dal repository Drupal ufficiale, quindi non dovrebbe essere considerata parte del codice che abbiamo scritto / mantenuto, ma la riscrittura è stata fatta con il framework Kohana, quindi tutto è stato fatto da zero.

Le buone notizie erano:

• Prima di rifarlo, ho avuto più di 1 anno di esperienza di manutenzione / estensione di questa app, due dei miei colleghi hanno avuto il doppio del tempo in meno di tale esperienza. Un ultimo ragazzo non ha avuto esperienza.
• Durante il periodo di manutenzione abbiamo gradualmente migliorato alcune parti e trovato la maggior parte delle insidie e delle funzionalità non documentate.
• Prima di riscrivere siamo riusciti a fare una specifica di qualche tipo.
• Negli ultimi mesi abbiamo aggiunto alcune nuove parti che avremmo mantenuto nella nuova versione. Alcuni di questi codici sono stati effettivamente trapiantati.

Come è successo:

• È stato fatto principalmente da due ragazzi, uno di loro era il ragazzo senza esperienza di manutenzione. Ho aiutato con le specifiche e solo un po 'con il codice. Un ragazzo ha mantenuto la vecchia versione attraverso il processo.
• Ci sono voluti poco più di un anno e mezzo, ma in parte perché i manager hanno mantenuto un nuovo concetto di interfaccia e un design grafico. Solo la codifica potrebbe essere fatta in 4-5 mesi, penso.
• Quasi tutte le vecchie funzionalità sono ora implementate, alcune anche leggermente migliorate.
• Sono stati effettuati alcuni test di unità rudimentali (ma non TDD / BDD), non l'ho ancora esaminato.

Dopo tutto, la nuova versione è online e non abbiamo grossi problemi.

Non era una riscrittura del 100% perché:

• Abbiamo preso un po '(ma poco) codice per la nuova versione
• La vecchia versione stava effettivamente subendo il processo di miglioramento graduale, quindi non era un enorme "cambio di paradigma" per noi come sviluppatori

Senza quella parte di manutenzione probabilmente non si potrebbe fare. Tendo ad essere d'accordo con altre risposte in quanto la riscrittura completa è generalmente una cattiva idea, ma come la nostra storia mostra, è possibile dare quelle condizioni:

• l'app non è molto grande
• il team non è molto grande (4 nel nostro caso)
• la maggior parte dei membri del team ha una vasta conoscenza ed esperienza che si occupa del codice legacy

Per la tua situazione specifica ti posso suggerire:

1. Cerca di migliorare ciò che hai. Questo ti darà almeno una conoscenza approfondita della tua app.
2. Se il miglioramento funzionerà, considera di continuare a migliorare anche senza passare al tuo attuale stack tecnologico. Un uccello in mano vale due nella boscaglia, lo sai.
3. Se il miglioramento avrà esito negativo, la riscrittura sarà più facile e veloce a causa della clausola 1 nell'elenco.