Advice on working with legacy code

Question

I need some advice on how to work with legacy code.

A while ago, I was given the task to add a few reports to a reporting app. written in Struts 1, back in 2005. No big

Answer 1

Legacy code is a big issue, and I'm sure people will not agree!

I would say that starting a big re-factor could be a mistake.

A big re-factor means doing a lot of work to make it function exactly the way that it does now. If you choose to take this on on your own, there won't be a lot of visibility of what you are doing. If it works, no one will know the hours of work you put it. If it does NOT work, and you end up with tidy code, but add some bugs (and who has ever written code without adding some bugs) then you will get 'why did this change' type questions.

I have currently nearly completed a project working on a 10 year old code base. We have done quite a few bits of re-factoring along the way. But for each re-factor we have made we can justify 'this specific change will make the actual task we are doing now easier'. Rather than 'this is now cleaner for future work'. We have found that as we worked on the code, fixing the issues that we actually come up against one at a time, we have cleaned up a lot of it, without breaking it (much).

And I would say before you can re-factor much, you will need automated tests, so you can be fairly happy that you have put it back together right!

Most re-factoring is done to 'make maintenance and future development easier'. Your project sounds like there is not a lot of future development coming. That limits the advantage a re-factor will give the company.

Answer 2

In a few words: before make any modifications to legacy code its good idea to start from automated unit tests. This will give developer understanding about key things: dependencies this piece of code has, input data, output results, boundary conditions so on.

When it’s done most likely you will better understand what this code does and how it works.

After that its make sense (but not must) clean code a bit giving more accurate names to local variables, moving some functionality (repetitive code, if any) in to functions with clear human friendly names.

A simple clean up could make code more readable and at the same time save developer from regression issues with unit tests help.

Refactoring – make small changes, step by step, when you have a time and understanding of the requirements and functionality, regularly unit testing the code.

But do not start from refactoring

Answer 3

I agree with other comments. If you don't have to, then don't do it. It usually cost far more then it's worth if the code base is more or less dead any way.

On the other hand, if you feel that you cannot get your head around the code then a refactor is probably unavoidable. If this is the case then, since it's a web application, can you create a solid suite of functional tests using selenium? If so this is the fastest and most rewarding test approach for such code and will catch most bugs for the buck.

Second, start with the extract method refactoring to create compose methods of the big difficult methods. Every time you think to your self "This should have a comment to explain what it does" you should extract it to a method with a name that replaces the comment.

Once this has been done, if you still can't add the functionality required, you can go for more advanced refactorings, and perhaps even adding some unit tests. But I usually find that I can add what is required/fix the bug in legacy code by just creating self documenting code.

Answer 4

Rule #1: If it ain't broke, don't fix it.

Rule #2: When in doubt, reread rule #1.

Unfortunately, legacy code can very rarely be described as "it ain't broke." Therefor we must tweak the existing code to correct a newly found bug, tweak the existing code to modify behavior that was previously acceptable, or tweak the existing code to add new functionality.

My experience has taught me that any refactoring must be done in 'infinitesimally' small increments. If you must break rule #2, I suggest that you start your search with the inner-most nested loop or IF structure and expand outward until you find a clean, logical separation point and create a new function/method/subroutine that contains only the guts of that loop or structure. This won't make anything more efficient but it should give you a clearer view of the underlying logic and structure. Once you have several new, smaller functions/methods/subroutines you can refactor and consolidate those into something more manageable.

Rule #3: Ignore my previous paragraph and reread the first two rules.