Ho una domanda metodologica. Mi trovo di fronte a un sistema legacy abbastanza grande (Java Enterprise). Sono nuovo nel suo codebase - come tutti i membri del team - poiché è un prodotto che avevamo in outsourcing che gli uomini d'affari hanno deciso di portare in casa perché è diventato cruciale per il business.
Lo stato attuale del progetto è:
- Non è disponibile nessuno che abbia lavorato su quel sistema (eccetto uno senior dev), questo implica che abbiamo poche conoscenze su come effettivamente il sistema funzioni internamente.
- Il codebase è progettato molto male (nessun test, scarsa o addirittura inesistente progettazione OO)
- L'architettura è complessa e non molto ben documentata
- Si integra con molti componenti / sistemi di terze parti
- È di importanza critica per l'azienda (opera 24 ore su 24 anche nell'elaborazione di transazioni finanziarie).
- Abbiamo paura di apportare modifiche perché, senza una corretta copertura di test, non sappiamo se rompiamo le cose. Ricorda che il denaro è coinvolto.
- Non è possibile un corretto test delle unità poiché non esiste un design OO. Solo i test di integrazione black-box sono in qualche modo fattibili (essere consapevoli delle interazioni sincrone e asincrone che ha con sistemi di terze parti come i servizi di pagamento).
- La scarsa progettazione OO rende difficile l'identificazione, l'isolamento e il calcolo di singole funzionalità del sistema.
La domanda è: come ti avvicineresti alla reingegnerizzazione di questo mostro? Vogliamo acquisire fiducia nei suoi interni, migliorare decisamente la progettazione e la testabilità OO .... ma come iniziare in sicurezza?
Idealmente dovremmo essere una squadra agile ma con questo punto di partenza non sono sicuro del modo migliore per affrontare questo problema. Finora abbiamo iniziato ad aggiungere alcuni test di integrazione, ma in ogni caso non siamo fiduciosi di alcuna mossa che prendiamo ... Non abbiamo alcun oracolo / documento che ci dica se stiamo rompendo le cose.