2

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.

gnat
  • 21,442
  • 29
  • 112
  • 288
jjengineer
  • 29
  • 1
  • I thinks this question might be too broad or opiniated for SO, that would already be 2 good reasons for it to be closed. My first advice would be to stop thinking about any new functionality for the next months and focus on documenting the codebase and writing tests as you do so. That would be for the dev part. Ops part can't be bypassed of course, and that's where the senior dev with project knowledge will come into play... – Laurent S. Jul 16 '15 at 08:41
  • Thanks! However stopping new functionalities is unacceptable from the business perspective. Adding tests is easy in theory, extremely difficult in practice (but I agree we must do it). Concerning the topic of the question, it has been originally posted on the main SO and they suggested to post it here.....Thank you again. – jjengineer Jul 16 '15 at 08:50
  • Is the source code is in plain text files (like Java, PHP etc.) or is it in a proprietary format that requires a propietary IDE to open them (like PowerBuilder or Oracle Forms)? My answer depends on this. – Tulains Córdova Jul 16 '15 at 13:28

1 Answers1

2

I've been in a similar situation, we ended up saving all input and output files to/from the system in production. With them in hand we could build a test setup and have a test harness (did running the input files still give the same output files).

Then we could slowly start to refactor and uncover what the system requirements actually were and in the end rewrite major parts.

KyleL
  • 105
  • 3
Kim
  • 21
  • 1