Raccomandazioni per la migrazione di un'app Web legacy in un framework moderno

Question

Attualmente sto lavorando per un'azienda che esegue un'app web legacy costruita su Java Servlet (il sistema è pre-data JSP, anche se ora li usano quando costruiscono nuove pagine). La base di codice è un grande caos confuso come i suoi circa 10 anni di costruzione in cima a un quadro obsoleto. Hanno poca coerenza nella base di codice (l'app è stata sviluppata da varie persone nel corso degli anni, la maggior parte delle quali non funziona più qui), nessun concetto di DRY (ogni pagina è fondamentalmente creata da zero) un sacco di illeggibile/criptico codice e, in generale, un'infrastruttura molto incoerente.

Come ho lavorato qui, ho aggiunto funzionalità moderne/cercando di ripulire un po 'il codice base. Ho aggiunto un po 'di jQuery a dove sono stato esposto, introdotto un po' di sicurezza con le convalide degli input, ripulito alcuni dei moduli per utilizzare principi JavaScript non invadenti, ecc. Il mio lavoro qui è sui nuovi moduli quindi non sono esposto a molto del vecchio logica. Ho cercato di introdurre le migliori pratiche per tutto il mio lavoro sotto la loro attuale infrastruttura, ma sono costretto a chiamare molto del loro vecchio codice per rendere le mie cose coerenti.

Hanno raggiunto un punto in cui stanno ora considerando un enorme aggiornamento del sistema. Vogliono migliorare la manutenibilità della base di codice e tentare di passare a una sorta di applicazione di tipo framework/MVC moderna. Gran parte del sistema precede XHTML con markup stilistico in linea, chiamate javascript: function(), nessun test unitario, precede Hibernate, ecc. Esiste un mix di generazione html out.println e chiamate jsp dall'interno del servlet.

Alcune app che hanno visto includono Wicket, Struts, Tapestry e possibilmente Grails. Il problema è che il passaggio a uno di questi potrebbe richiedere un'enorme riscrittura di un sistema già in uso e che non possono permettersi di ricominciare.

La mia domanda è: quale sarebbe il modo migliore per migrare un codice legacy come questo in un framework più moderno mantenendo la logica aziendale esistente (non ha senso riscrivere materiale che è stato testato e funziona).

Alcune delle idee essere pensato includono:

• scrive un sistema di template casa che avrebbe funzionato con la loro attuale infrastruttura (generare pagine in modo coerente)

• codice del porto ad un quadro, come arazzo (riutilizzo di un sacco di loro vecchio codice)

• sistema di riscrittura da zero utilizzando un quadro moderno, ma la copia sulla logica da vecchio sistema (se possibile)

• mantenere il vecchio sistema, come è e basta aggiornare le pagine di front-end per dare un aspetto più moderno (potrebbe essere migliore dato tempo/denaro, ecc)

qual è il modo migliore per aggiornare l'eredità Il codice Java Servlet in un framework moderno (usando pratiche moderne per una facile manutenzione, unit test, DRY) mantenendo intatta la logica?

qualsiasi approfondimento è benvenuto.

Answer 1

Rifattorici a morte, lavorando verso uno stile coerente di design, come preliminare per portarlo sulla struttura più vicina allo spirito a qualsiasi stile.

Con "refactor" intendo: introdurre test in posizioni strategiche, unità oltre che funzionali, e lavorare come matti per ridurre le duplicazioni, appoggiandosi a questi test.

Answer 2

Il modo migliore: utilizzare l'app esistente come specifica funzionale e creare la nuova app da zero (con alcuni possibili riutilizzo di cut-n-paste o riutilizzo effettivo della classe dove ha senso).

Dalla mia esperienza, provare a calzare un'app legalmente scritta in un nuovo framework o provare a "incastrare" il codice junk con un buon codice porta solo a qualcosa che è ancora più difficile e costoso da mantenere a lungo termine.

Answer 3

Non esiste una risposta chiara per questo tipo di domanda, ma il mio suggerimento principale sarebbe quello di leggere prima l'argomento sull'oggetto. Leggi i libri di persone che conoscono le cose di cui stanno parlando.

Ad esempio, Code Complete (Steve McConnell), cap. 24 refactoring.

• Salva il codice che inizia con

• Tenere refactoring piccoli

• Effettuare una refactoring alla volta

• Refactor quando si aggiunge una routine, di classe, correggere un difetto

• Definire un'interfaccia tra codice pulito e brutto

• ...

Ci sono molte altre risorse, stampati e on-line, che è possibile utilizzare. Successivamente, se hai una domanda più specifica, puoi utilizzare siti come SO per ottenere una risposta più utile di questa.

Answer 4

ho fatto una domanda molto simile qualche mese fa, alcune delle risposte potrebbero essere utili per voi:

What is the best way to migrate an existing messy webapp to elegant MVC?

Answer 5

questo è solo la mia opinione, perché penso che questa domanda è che cosa la gente paga costoso consulenti per allenarsi (e di solito finiscono solo a sprecare soldi! vedi thedailywtf.com per gli esempi).

Penso che non valga la pena una completa riscrittura, perché durante il processo di riscrittura, potrebbe essere necessario mantenere anche l'app originale *, e quindi la riscrittura avrà un obiettivo mobile. il modo migliore è ripagare il debito del codice come refactoring - ad esempio, occorreranno 2x, 3x o anche 10 volte lo sforzo di implementare una semplice funzionalità, semplicemente perché farlo in un modo carino comporta il refactoring degli heap. ma questo sforzo è necessario, in quanto il debito dovuto in questa app è elevato e alla fine deve essere pagato in qualche modo.

può far male, ma una buona medicina fa male.

• se si è data una buona fetta di tempo per fare la riscrittura, vale a dire, l'applicazione originale è congelato e non mantenuta (nemmeno correzioni di bug), allora potrebbe funzionare come una completa riscrittura in qualunque quadro si ritengono in forma. ma dubito fortemente che questo sarà il caso in ogni istituzione.