Come avvicinarsi a questo progetto Java legacy? [duplicare]

Naviga le tue risposte
4

Modifica: Supponiamo che rimarrò su questo progetto fino alla "fine".

Il problema

Attualmente sto lavorando a un progetto legacy interessante Java. Una riscrittura completa è al momento fuori discussione, poiché sto lavorando da solo e la funzionalità corrente desiderata era mesi fa (prima di entrare nel progetto).

È piuttosto grande e include:

  1. JDK 1.5
  2. Copertura di test essenzialmente 0%
  3. 7 progetti Java separati che contengono una molto build circolare
  4. Ant e Maven (che voglio aggiornare in Gradle)
  5. Un'app GUI Java Webstart
  6. Drools 5.5 (gestisce quasi tutte le funzionalità importanti)
  7. 3 server Apache Tomcat (con Apache Axis, che è stato aggiornato l'ultima volta nel 2006)
  8. e molte altre librerie deprecate che ... fanno cose

L'ho fatto compilare e girare correttamente in un nuovo ambiente di sviluppo, e ho aggiornato JDK a partire da 1.5 e ho iniziato a usare 1.6 / 1.7 / 1.8 dove posso. Ho anche aggiornato Drools a 5.6. Ho appena ottenuto il progetto a un punto in cui è possibile apportare modifiche e verificarlo in modo un po 'sane mentre lo si esegue in un ambiente non deprecato. Tuttavia, ci sono molte aree del codice in cui pezzi di grandi dimensioni sono stati copiati negli altri progetti e da allora sono stati mantenuti in modo diverso. Sono in gran parte insicuro di cosa fa qualsiasi cosa - al di fuori del "flusso principale".

Che cosa @! # $? mi sono cacciato?

Quello che voglio , è quello di refactoring questa cosa in un senso che ha un senso, ma non mi prende troppo a lungo. Stavo pensando di rippare tutti i tipi e qualsiasi funzionalità la stiano facendo circolare in un progetto "SharedJunk" separato?

Tuttavia, ciò di cui ho bisogno , è quello di ottenere nuove funzionalità, ed è stato chiesto ieri.

Semplicemente sbatto la faccia per sfornare di più la stessa qualità di lavoro che ha portato questo progetto in questo stato di morte quasi impossibile da impedire? O faccio refactoring? C'è una quantità infinita di pulizia da fare.

Il mio capo è molto paziente e vuole che questo "sia fatto nel modo giusto", tuttavia, sta combattendo le pressioni di altre aree dell'azienda e sento che potrebbe non resistere per sempre.

Le opzioni

  1. Refactor per sempre
  2. Rifattore il minimo indispensabile
  3. Colpisci la mia faccia nel nuovo codice
  4. Cry

Qualunque consiglio generale su cosa fare in questo tipo di progetto sarebbe molto apprezzato. Attualmente sto rileggendo il Working Effectively With Legacy Code e il Refactoring to Patterns. Posso chiarire questo, ma non sono sicuro di cosa aggiungere.

Grazie.

    
posta Nathan 01.12.2017 - 18:22
fonte

2 risposte

3

Poiché non hai requisiti, i tuoi requisiti diventano essenzialmente: falla fare ciò che fa la vecchia cosa, finché non ti viene detto diversamente. So solo un modo per affrontare con successo questo.

Devi creare / acquisire / trovare quanti più dati puoi collegare all'uso di questo sistema. Cioè, hai bisogno di tonnellate di dati di input. Il volume è fondamentale in questa strategia. Esegui tutti i dati di input su cui puoi mettere le mani attraverso il codice esistente. Cattura tutti gli output organizzati in modo da poter collegare gli input agli output risultanti.

A seconda del sistema, questo potrebbe essere facile o potrebbe essere difficile. Se si tratta di un sistema stateless (non modifica stato), in genere è abbastanza semplice. Altrimenti, lo stato di aggiornamento è un output e devi catturarlo anche.

Quindi prendi gli stessi identici input (stato del database incluso) ed esegui quello attraverso la nuova versione e catturalo nello stesso modo come con il vecchio. Diff ogni nuovo output con il corrispondente vecchio output (con uno script) Potrebbe essere necessario ignorare / razionalizzare alcuni campi come timestamp e UUID. Qualsiasi cambiamento che trovi dovrebbe essere dovuto ai tuoi nuovi requisiti. Qualsiasi altra cosa è un errore di regressione o un "incidente felice" in cui hai riparato un bug involontariamente. Questi potrebbero non valere la pena di tenere a causa del tempo che possono aggiungere alla revisione dei risultati. La chiave qui è di massimizzare la quantità di test che corrispondono esattamente e minimizzare il numero di cose che devi valutare a occhio. Se puoi automatizzare le convalide non corrispondenti, è una grande vittoria.

Questo non è a prova di proiettile con qualsiasi mezzo. È solo buono come gli input che ci spingi dentro. Se ti perdi degli scenari, potresti ottenere un risultato che corrisponda a tutto e avere ancora problemi di regressione. Dato che non sai quali sono gli scenari (il codice potrebbe indurti a entrare) non c'è molto che puoi fare, ma cerca di ottenere molti input vari. Se qualcosa scivola via, non disperare. Trova solo alcuni dati che verificano gli scenari mancati e ripetili. Ho usato questo approccio molte volte e ho avuto risultati eccellenti. Spesso questo esporrà più problemi rispetto alle pratiche di test standard.

    
risposta data 01.12.2017 - 20:28
fonte
4

Non refactoring.

"fatto nel modo giusto" è solo il culo che copre e non il tuo!

  • Ottieni requisiti chiari e implementali con il numero minimo di modifiche al codice.

  • Ottieni l'accesso all'app e i requisiti sono soddisfatti.

risposta data 01.12.2017 - 18:27
fonte

Leggi altre domande sui tag

Le migliori pratiche per quando una dipendenza di terze parti si rompe? Dove dovrebbe essere effettuato il debouncing dell'evento, nell'emettitore o nel consumatore?