How would you maintain legacy applications

Question

How would you maintain the legacy applications that:

1. Has no unit tests have big methods

2. with a lot of duplicated logic have

3. have No separation of concern
4. have a lot of quick hacks and hard coded strings
5. have Outdated and wrong documentation
6. Requirements are not properly documented! This has actually resulted in disputes between the testers, developers and the clients in the past. Of course there are some non-functional requirements such as shouldn't be slow, don't clash and other business logics that are known to the application users. But beyond the most common-sense scenario and the most common-sense business workflow, there is little guidance on what should be ( or not) done.

???

Answer 1

Write tests as soon as you can. Preferably against the requirements (if they exist). Start with functional tests. Refactor in small chunks. Anytime you touch code, leave it cleaner and better than when you started.

Answer 2

Two things.

1. Write unit tests as you have the chance.
2. Once you have enough unit tests to be confident, start refactoring.

The rate at which you accomplish this may be slow.... Typically, you're supposed to "just maintain it" not fix it.

During the "learning how to maintain it" phase, however, you can write a lot of unit tests.

Then, as bugs are found and enhancements requested, you can add yet more tests.

It's Agile, applied to legacy.

Answer 3

I think I would create a small set of Up To Date information: What Action calls which functions etc.

From there, I would look at refactoring. Duplicated Logic seems to be something that could be refactored, but remember that

• That can be a huge task when you realize in how many many places that logic is called and
• Two function that seem similar may have a tiny difference, i.e. a - instead of a +

I think the biggest urge to resist is "Just rebuild the whole damn thing!" and get an overview of the system first, to demystify the beast.

Answer 4

I basically agree with everything Paul C said. I'm not a TDD priest, but anytime you're touching a legacy codebase -- especially one with which you're not intimately familiar -- you need to have a solid way to retest and make sure you've followed Hippocrates: First, do no harm. Testing, good unit and regression tests in particular, are about the only way to make that play.

I highly recommend picking up a copy of Reversing: Secrets of Reverse Engineering Software if it's a codebase with which you're unfamiliar. Although this book goes to great depths that are outside your current needs (and mine, for that matter), it taught me a great deal about how to safely and sanely work with someone else's code.

Answer 5

sudo rm -rf /

But more seriously, I think it has to be evaluated. If the code continually is a source of requests for change and the changes are difficult then before long you have to consider if it is worth it to try and refactor/re-engineer the system into something more modern. Of course this isn't always practical, so you often end up with just a few people on the team who are responsible for maintaining the legacy parts. As much as possible, everyone on the team should be able to maintain all parts of the system......

One more thing that I think is important is to track the amount of time and effort that a team spends working on a legacy system doing maintenance/feature requests. These metrics can be convincing when evaluating the planning of a new effort to replace the legacy systems/components.

Answer 6

I have seen, worked and am working in a codebase which satisfies all the conditions that is mentioned in the question :-)

The approach followed in maintaining this codebase is NOT TO BREAK ANYTHING. FWIW, the code works and the end users are happy. No one is going to listen to the developer cries that there is duplication of code, hard coded strings etc. We just steal some time to fix whatever possible and take the utmost care to not introduce new bugs..