Qual è il modo migliore per migrare una webapp disordinata esistente nell'elegante MVC?[Chiuso]

Question

Sono entrato in una nuova azienda circa un mese fa.L'azienda è di dimensioni piuttosto piccole e ha una forte sensazione di "start-up".Sto lavorando come sviluppatore Java in un team di altri 3.L'azienda vende principalmente un servizio ad aziende/persone di tipo aziendale da utilizzare per comunicare tra loro.

Una delle cose principali su cui ho lavorato e su cui lavorerò è il sito Web principale dell'azienda: da cui viene venduto il servizio, gli utenti esistenti accedono per verificare il servizio e pagare le bollette, i nuovi utenti possono registrarsi per una prova , eccetera.Attualmente si tratta di un'applicazione JSP distribuita su Tomcat, con accesso a un database effettuato tramite un livello di persistenza scritto dalla società stessa.

Una frustrazione ripetuta e crescente che provo qui (e sono abbastanza soddisfatto del lavoro nel complesso, quindi questo non è un post del tipo "oh no, non mi piace il mio lavoro") è la mancanza di un design più ampio o architettura per questa applicazione web.L'app è composta da diverse dozzine di pagine JSP, quasi senza logica esistente in Servlet o Bean o qualsiasi altro tipo di framework.Molte delle pagine JSP sono costituite da migliaia di righe di codice jsp:include altre pagine JSP, la logica aziendale è mescolata con l'HTML, i frammenti di codice utilizzati di frequente (come ottenere una connessione al servizio Web) vengono tagliati e incollati anziché riutilizzati, ecc.In altre parole, l'applicazione è un disastro.

Ci sono state alcune voci all'interno dell'azienda riguardo al tentativo di riprogettare questo sito in modo che si adatti meglio a MVC;Penso che gli sviluppatori e i piani alti stiano cominciando a rendersi conto che questo attuale modello di codice spaghetti non è sostenibile o facilmente scalabile per aggiungere più funzionalità per gli utenti.I vertici e gli sviluppatori sono cauti nel riscrivere completamente il prodotto (con una buona ragione, poiché ciò significherebbe diverse settimane o mesi di lavoro per riscrivere le funzionalità esistenti), ma abbiamo discusso di (lentamente) ri- scrivere alcune aree del sito in una nuova struttura.

Quali sono alcune delle migliori strategie per consentire di spostare l'applicazione e la base di codice in questa direzione?Come posso, come sviluppatore, aiutare davvero a portare avanti tutto questo, e rapidamente, senza sembrare il nuovo ragazzo idiota che entra in un lavoro e dice a tutti che quello che hanno scritto è una schifezza?Ci sono strategie o esperienze comprovate che hai utilizzato nella tua esperienza lavorativa quando ti sei imbattuto in questo genere di cose?

Answer 1

La soluzione migliore è probabilmente rifattorizzarlo lentamente man mano che procedi.Pochi di noi hanno le risorse necessarie per iniziare completamente da zero con qualcosa che contiene così tante regole aziendali sepolte.Il management odia davvero quando passi mesi a sviluppare un'app che ha più bug di quella che hai sostituito.

Se hai l'opportunità di creare app separate da zero, utilizza tutte le migliori pratiche disponibili e usale per dimostrare quanto siano efficaci.Quando puoi, incorpora queste idee gradualmente nella vecchia applicazione.

Answer 2

Per prima cosa prendi una copia di Working di Michael Feather Efficacemente con il codice legacy.Quindi identificare il modo migliore per testare il codice esistente.Il caso peggiore è che sei bloccato solo con alcuni test di regressione di alto livello (o niente) e se sei fortunato ci saranno test unitari.Quindi si tratta di un caso di refactoring lento e costante, si spera, aggiungendo allo stesso tempo nuove funzionalità aziendali.

Answer 3

Nella mia esperienza, l'"eleganza" di un'app in genere ha più a che fare con la progettazione del database che con qualsiasi altra cosa.Se hai un Grande progettazione del database, inclusa un'interfaccia di procedura memorizzata ben definita, un buon codice applicativo tende a seguire indipendentemente dalla piattaforma utilizzata.Se hai povero progettazione del database, indipendentemente dalla piattaforma utilizzata, avrai difficoltà a creare un codice applicativo elegante, poiché compenserai costantemente il database.

Ovviamente c'è molto spazio in mezzo Grande E povero, ma il punto è che se vuoi un buon codice dell'applicazione, inizia assicurandoti che il tuo database sia all'altezza.

Answer 4

Questo è più difficile da fare nelle applicazioni che sono solo in modalità di manutenzione perché è difficile convincere il management che vale la pena riscrivere qualcosa che già "funziona".Inizierei applicando i principi di MVC a qualsiasi nuovo codice su cui puoi lavorare (ad es.spostare la logica aziendale in qualcosa di simile a un modello, mettere tutto il codice di layout/visualizzazione in un unico posto)

Man mano che acquisisci esperienza con il nuovo codice in MVC, puoi iniziare a vedere opportunità per modificare leggermente il codice esistente in modo che anch'esso sia in linea.Può essere un processo molto lento, ma se riesci a mostrare i vantaggi di questo modo di farlo, sarai in grado di convincere gli altri e coinvolgere l'intero team.

Answer 5

Sarei d'accordo con l'approccio del refactoring lento;ad esempio, prendi quel codice copia e incolla ed estrailo in qualunque sia il paradigma Java appropriato (una classe, forse?o meglio ancora, utilizzare una libreria esistente?).Quando il tuo codice è veramente pulito e conciso, ma ancora privo di una strategia architettonica complessiva, Poi sarai in grado di adattare le cose a un'architettura complessiva molto più facilmente.

Answer 6

Il modo migliore è stampare il codice, accartocciarlo e buttarlo via.Non riciclare nemmeno la carta.

Hai un'applicazione scritta in JSP lunghi oltre 1.000 righe.Probabilmente ha un modello di dominio terribile (ammesso che ne abbia uno) e non si limita a MISCELARE la presentazione con la logica aziendale, ma lo UNISCE e rimane lì e continua a mescolare per ore.Non c'è modo di eliminare il codice che è scadente e spostarsi in una classe Controller MVC e continuare a fare la cosa giusta, ti ritroverai semplicemente con un'app MVC con un modello di dominio anemico o uno che ha cose come le chiamate al database nel codice del controller, stai ancora fallendo.

Potresti provare una nuova app che fa la cosa giusta e poi far sì che le due app comunichino tra loro, ma questa è di per sé una nuova complessità.Inoltre probabilmente farai la stessa quantità di lavoro che avresti fatto se avessi iniziato da zero, ma potresti avere più difficoltà a cercare di convincere i tuoi capi che questo è un approccio migliore.

Answer 7

Refactoring iterativo.Cerca anche nuove funzionalità che possono essere implementate completamente nel nuovo framework come un modo per mostrare il valore del nuovo framework.

Answer 8

Il mio suggerimento sarebbe quello di trovare le rare pagine che non richiedono l'importazione di altri JSP o che hanno pochissime importazioni.Tratta ogni JSP importato come una scatola nera e rifattorizza queste pagine attorno ad esso (iterativamente, testando ogni modifica e assicurandoti che funzioni prima di continuare).Una volta ripuliti, puoi continuare a trovare pagine con sempre più importazioni, fino a quando non avrai effettuato il refactoring delle importazioni.

Durante il refactoring, prendi nota delle parti che tentano di accedere alle risorse non fornite alla pagina e prova a sottoporle a un controller.Ad esempio, tutto ciò che accede al database dovrebbe essere all'interno di un controller, lasciare che sia il JSP a gestire la visualizzazione delle informazioni fornite dal controller tramite un forward.In questo modo svilupperai diversi servlet, o cose come servlet, per ogni pagina.Suggerirei di utilizzare un framework basato su front-controller per questo refactoring (per esperienza personale consiglio Spring e la sua interfaccia Controller), in modo che ciascun controller non sia un servlet separato ma sia piuttosto delegato da un singolo servlet mappato in modo appropriato.

Per il controller, è meglio eseguire tutti gli accessi al database in una volta anziché tentarli frammentariamente.Gli utenti possono e generalmente tollerano il caricamento di una pagina, ma l'output della pagina sarà molto più veloce se tutti i dati del database vengono forniti al codice di rendering anziché il codice di rendering sospeso e non fornisce dati al client mentre sta tentando di leggerne ancora un altro pezzo di dati dal database.

Sento il tuo dolore e ti auguro buona fortuna in questa impresa.Ora, quando devi mantenere un'applicazione che abusa di Spring Webflow, quella è un'altra storia :)