Qual è l'approccio migliore per il controllo di una grande applicazione web java/j2ee

Question

Devo controllare una grande applicazione Java/J2ee web che si è evoluta su diversi anni. È stato scritto da un'altra società, non quella per cui lavoro. In lo stato corrente è diventato difficile da evolvere e mantenere, le nuove funzionalità di sono difficili da aggiungere e spesso portano a bug che a volte si presentano nella produzione . Sembra che ci sia del codice copia/incollato che ha provocato la duplicazione del codice. L'app attuale è una sorta di shopping online con qualche contenuto simile a cms qua e là. Sono principalmente Struts e alcuni Spring in parti più recenti del codice, forse alcuni ejbs lanciati per la misura giusta . Ci sono alcuni test unitari disponibili, ma non molti di loro. Queste sono cose che mi è stato detto, non ho ancora visto il codice attuale.

La mia azienda farà una proposta di riscrivere parti di questa applicazione al fine di ridurre la complessità , migliorare la qualità e la modularità, e permettono di aggiungere più facili nuove funzionalità, senza regressioni. Prima di prendere qualsiasi iniziativa, vorrebbero avere un qualche tipo di apprezzamento della qualità del codice esistente e di valutare quanto di esso possa essere riutilizzato, in modo da avere più di un'ipotesi su ciò che ci sarà da fare nell'ordine fatto - riscrittura completa o parziale riscrittura .

Il problema è che dovrò farlo in un periodo molto breve (un paio di giorni) quindi sono cercando di elaborare un piano per ciò che può essere fatto in così poco tempo. Quello che sto thiking è:

• check-out "di base" le cose - Trattamento delle eccezioni, la registrazione
• check out il livello di stratificazione (vista, controllori, strato DAO)
• misurare l'effettiva copertura del unità di test
• forse eseguire alcuni Checkstyle, Findbugs e PMD sui progetti
• ...

Quindi la domanda reale è ciò che altre cose sh posso prendere in considerazione/controllare/misurare/etc?

io non sono sicuro di che tipo di numeri ho potuto uscire da questo, e se sarebbe davvero significare qualcosa, ho la sensazione che ciò che la gestione sta chiedendo è una specie di sbagliato l'approccio , in modo che il secondo quesito sarebbe: qualcuno ha un'idea migliore?

Apprezzerò qualsiasi idea, suggerimento, commento su questo.

Edit: Sarò l'aggiunta di due rivelatori di codice morto al mix: UCD e DCD

Answer 1

Avevo due applicazioni Web con impostazioni simili. Ho smesso di usare FindBugs e Checkstyle perché hanno mostrato più di 10.000 punti problematici. Le applicazioni utilizzavano l'accesso ai dati a livello JDBC, JSP per la presentazione e un framework personalizzato per l'invio delle richieste. Fortunatamente per me, queste impostazioni di basso livello mi hanno permesso di eseguire estensioni e correzioni a difficoltà media. Durante il progetto di 3 anni, solo il 20% circa del codice originale è rimasto come era. Prima o poi tutto il resto doveva essere cambiato, sostituito o rimosso (e finalmente sono stato in grado di usare FindBugs e Checkstyle).

Anche noi abbiamo affrontato il dilemma della completa riscrittura. Tuttavia, c'erano diversi fattori:

• Non sicuro che il cliente pagherà per una completa riscrittura.
• La mancanza di documentazione funzionale e tecnica rende rischioso eseguire la riscrittura completa.
• Manodopera per comprendere appieno l'applicazione completa era troppo alta. Il cliente desiderava prima le modifiche richieste.
• Gli utenti in cui sono stati personalizzati per la presentazione e il comportamento della pagina. Sembrava difficile convincere gli utenti a utilizzare una nuova interfaccia per le vecchie funzioni.
• Se eseguiamo una riscrittura completa, è necessario fornire una documentazione completa. Per l'aggiornamento, dovevamo documentare solo la nostra parte.
• È difficile convincere la gestione (propria e del cliente) di una riscrittura se il programma funziona (più o meno)
• La società ha le proprie regole PMD e il codice non è passato. È stato più semplice sostenere che è sufficiente che le nuove parti superino il test.

Si riduce a ciò che si vuole fare in realtà.

Vuoi riscrivere, nonostante la complessità?

• Mettere l'accento sui bug del codice. I grandi grafici a torta con molto rosso sono convincenti.
• Spiegare le proprietà del programma e il modo in cui non rientrano nella visione aziendale.
• Mostra le opzioni di miglioramento oltre i requisiti attuali e descrive come la versione corrente non è all'altezza della sfida.
• Fare interviste con gli utenti reali. Potrebbero segnalare problemi importanti con la versione corrente.
• Essere economico ma un buon estimatore. Potresti ritardare alcuni costi fino alla fase di manutenzione.

Non si desidera riscrivere?

• Mettere l'accento sul costo, in particolare sugli orari di lavoro richiesti dal cliente per ricontrollare tutto.
• Indicare il potenziale problema di interruzione della funzionalità.
• Richiedi uno scrittore di documenti a tempo pieno.

Se si desidera assaggiare il codice, provare ad aggiungere Hello World! funzione/schermo all'applicazione. Questo dimostra quanto sia difficile e quanto velocemente è possibile implementare nuove cose.

Answer 2

mi piace la vostra lista un bel po '. Penso che tu abbia un eccellente piano di attacco per iniziare.

Guarderei con occhio alla standardizzazione su Spring o EJB 3.0 ma non su entrambi.

Non l'ho letto da solo, ma mi chiedo se il libro di Michael Feathers "Working Effectively With Legacy Code" abbia qualche buona idea?

UPDATE:

Forse si può aiutare le cose mettendoli su una generazione automatica e l'integrazione continua - Cruise Control, Hudson, o Team City. Se devi fare qualsiasi refactoring ti sarà d'aiuto.

Answer 3

Ti stai concentrando sulla manutenibilità e sull'estensibilità che è azzeccata.

Vorrei aggiungere guardando quanto tempo ci vorrà per riavviare il progetto. Usano il controllo del codice sorgente? Hanno ambienti separati per l'integrazione e test di accettazione degli utenti? C'è un server di build?

Quando devi trascorrere due mesi prima che il primo miglioramento appaia, qualcuno deve gestire le aspettative del cliente in anticipo.

Answer 4

In realtà essi non pagheranno per una riscrittura completa, perché:

• E 'la recessione, il costo di voi riscrivere da zero sarà alto

• Essi potrebbero essere cercando di vendere l'azienda ASAP

• la gestione non capisce niente di sviluppo del software

Desidero in primo luogo andare con alcuni semplici fatti:

• utilizzare uno strumento per visualizzare lo SLOC del progetto
• Esegui come pianificato FindBugs e alla fine PMD, solo per stimare i difetti
• fare una rapida profilatura sessione
• Controllare i diversi strati
• Vedi (connessioni Streams, Hibernate o JDBC, ecc) se le risorse sono generalmente chiusi
• Vedi se le tecnologie sono utilizzate in cui esse non si applicano (EJB, Web Services, etc.)
• vedere come gestire le eccezioni e la registrazione
• vedere se c'è troppo o non abbastanza astrazione
• Vedere se è possibile aggiungere alcune classi di base per ridurre la duplicazione del codice

provare a disegnare un diagramma veloce l'architettura dell'applicazione, se non ti danno un documento a riguardo.

Raccogliere alcune statistiche e alcuni dati, scrivere un rapporto e inviarli alla società. Vogliono minimizzare i costi e ti chiederanno di evitare di correggere il codice che non è rotto. Si inizia con le statistiche, quindi con i fatti e una proposizione con tempo/percentuale approssimativa del codice interessato/prezzo.

Di solito le applicazioni legacy Struts sono una pita da mantenere, è stato fatto. Se non fosse parte del tuo lavoro, direi di lasciar perdere. Se trovi pagine "standalone" che non coinvolgono molti modelli e sono soggette a molte modifiche, proponi di riscriverle con altre tecnologie.