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

Question

Devo controllare un'applicazione Web Java / J2ee di grandi dimensioni che si è evoluta su diversi anni. È stato scritto da un'altra compagnia, non quella per cui sto lavorando. Nel allo stato attuale è diventato difficile evolvere e mantenere, nuovo le funzionalità sono difficili da aggiungere e spesso portano a bug che a volte si presentano produzione. Sembra che ci sia del codice copia / incolla che ha provocato la duplicazione del codice. L'attuale app è una specie di shopping online con alcuni contenuti simili a cms qua e là. È principalmente Struts e un po 'di primavera nelle parti più recenti del codice, forse alcuni ejbs lanciati buona misura. Sono disponibili alcuni test unitari, ma non molti. Queste sono cose che mi hanno detto, non ho ancora visto il codice reale.

La mia azienda farà una proposta per riscrivere parti di questa app al fine di ridurre complessità, migliorare la qualità e la modularità e rendere più semplice l'aggiunta nuove funzionalità senza regressioni. Prima di prendere qualsiasi impegno, vorrebbero avere un qualche tipo di apprezzamento della qualità del codice esistente e valutare in che misura può essere riutilizzato, in ordine avere più di una supposizione su ciò che dovrà essere fatto: riscrittura completa o parziale riscrivere.

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

• controlla " base " cose - trattamento delle eccezioni, registrazione
• controlla il livello di stratificazione (viste, controller, dao layer)
• misura l'effettiva copertura dei test unitari
• magari esegui Checkstyle, Findbugs e PMD sui progetti
• ...

Quindi la vera domanda è quali altre cose dovrei prendere in considerazione / controllare / misurare / etc?

Non sono sicuro che tipo di numeri potrei ottenere da questo e se significherebbe davvero qualcosa, ho la sensazione che ciò che la direzione sta chiedendo sia un po 'sbagliato approccio, quindi la seconda domanda sarebbe: qualcuno ha un'idea migliore?

Apprezzerò qualsiasi idea, suggerimento, commento su questo.

Modifica: aggiungerò due rilevatori di codici morti al mix: UCD e DCD

Answer 1

Avevo due applicazioni web con impostazioni simili a te. Ho smesso di usare FindBugs e Checkstyle in quanto 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 fare le estensioni e le correzioni a media difficoltà. Durante il progetto di 3 anni, solo il 20% circa del codice originale è rimasto così com'era. Prima o poi tutto il resto doveva essere modificato, sostituito o rimosso (e finalmente sono stato in grado di utilizzare FindBugs e Checkstyle).

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

• Non sono sicuro che il cliente pagherà per una riscrittura completa.
• La mancanza di documentazione funzionale e tecnica rende rischioso eseguire la riscrittura completa.
• Manhours per comprendere appieno l'applicazione completa era troppo alta. Il cliente voleva prima le modifiche richieste.
• Gli utenti 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, dobbiamo fornire la 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à aveva le proprie regole PMD e il codice non è stato approvato. È stato più semplice sostenere che è sufficiente che le nuove parti superino il test.

Si riduce a ciò che si desidera fare effettivamente.

Vuoi riscrivere, nonostante la complessità?

• Metti l'accento sui bug del codice. I grafici a torta di grandi dimensioni con molto rosso sono convincenti.
• Spiega le proprietà del programma e come non rientrano nella visione aziendale.
• Mostra le opzioni di miglioramento oltre i requisiti attuali e descrivi come la versione corrente non è all'altezza della sfida.
• Fai interviste con utenti reali. Potrebbero evidenziare problemi importanti con la versione corrente.
• Sii economico ma un buon stimatore. Potresti ritardare alcuni costi fino alla fase di manutenzione.

Non vuoi riscrivere?

• Metti in risalto il costo, in particolare le ore di lavoro richieste dal cliente per testare nuovamente tutto.
• Sottolinea il potenziale problema di interrompere la funzionalità.
• Richiedi uno scrittore di documenti a tempo pieno.

Se vuoi assaggiare il codice, prova ad aggiungere Hello World! funzione / schermo per l'applicazione. Questo dice quanto è difficile e quanto velocemente puoi implementare nuove cose.

Answer 2

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

• È una recessione, il costo per riscriverla da zero sarà alto

• Potrebbero provare a vendere la società APPENA POSSIBILE

• La direzione non capisce nulla sullo sviluppo del software

Vorrei prima andare con alcuni semplici fatti:

• Utilizza uno strumento per visualizzare lo SLOC del progetto
• Esegui come pianificato FindBugs ed eventualmente PMD, solo per stimare i difetti
• Esegui una sessione di profilazione rapida
• Controlla i diversi livelli
• Verifica se le risorse sono generalmente chiuse (stream, connessioni Hibernate o JDBC, ecc.)
• Verifica se le tecnologie vengono utilizzate laddove non si applicano (bean, servizi Web, ecc.)
• Scopri come gestiscono le eccezioni e la registrazione
• Vedi se c'è troppa o non abbastanza astrazione
• Verifica se potresti aggiungere alcune classi di base per ridurre la duplicazione del codice

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

Raccogli alcune statistiche e alcuni fatti, scrivi un rapporto e inviale alla compagnia. Vorranno ridurre al minimo 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 proposta con tempo / percentuale approssimativa del codice interessato / prezzo.

Di solito le applicazioni Struts legacy sono una pita da mantenere, ci sono già stato. Se non facesse parte del tuo lavoro, direi di lasciarlo andare. Se ti imbatti in " standalone " pagine che non coinvolgono molti modelli e sono soggette a molte modifiche, propongono di riscriverle con qualche altra tecnologia.

Answer 3

Ti stai concentrando sulla manutenibilità e sull'estensibilità, il che è perfetto.

Aggiungo guardando quanto tempo ci vorrà per riavviare il progetto. Usano il controllo del codice sorgente? Hanno ambienti separati per i test di integrazione e accettazione dell'utente? Esiste un server di build?

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

Answer 4

Mi piace molto la tua lista. Penso che tu abbia un eccellente piano di attacco per iniziare.

Guarderei con un 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 " ; Lavorare efficacemente con il codice legacy " ha qualche buona idea?

UPDATE:

Forse puoi aiutare le cose inserendole in una build automatizzata e integrazione continua: Cruise Control, Hudson o Team City. Se devi fare qualsiasi refactoring ti sarà di aiuto.