This question already has an answer here:
I have a methodological question. I am faced with a reasonably large legacy system (Java Enterprise). I am new to its codebase -as everybody in the team- since it's a product we had in outsourcing that the business people decided to bring in-house because it became business-critical.
The current state of the project is:
- There is nobody available who worked on that system (except one senior dev), this implies we have little knowledge about how actually the system internally works.
- The codebase is very poorly engineered (no tests at all, poor or even non-existent OO design)
- Architecture is convoluted and not very well documented
- It integrates with a lot of third party components/systems
- It's business critical (operates 24/7 also processing financial transactions).
- We are scared of doing any modifications because, without a proper testing coverage, we do not know if we break things. Remember that money is involved.
- No proper unit-testing is possible since there is no OO design. Only black-box integration testing is somehow feasible (be aware about the convoluted synch and asynch interactions it has with third-party systems like payments services).
- Poor OO design makes difficult to identify, isolate and factor-out single features of the system.
The question is: how would you approach the re-engineering of this monster? We would like to gain confidence about its internals, definitely improve its OO design and testability....but how to safely start?
Ideally we should be an agile team but with this starting point is am not sure about the best way to approach this problem. So far we started adding few integration tests, but in any case we are not confident about any move we take....We don't have any oracle/document that tell us if we are breaking things.