3 Hot Tips for Working With Legacy Code

Just about every seasoned developer I know has experienced of working in old, poorly maintained and buggy monolith codebases. There’s a plethora of reasons these projects exist from “It works, so why replace it” to “there’s no money in the budget to rewrite this.”

Here’s a few tips to make this process a little more bearable for developers lucky enough to be working on one of these.

1) Leave it better than you found it

There can be an overwhelming urge to dive in and fix every mistake or sloppy bit of code that you find, but generally this isn’t feasible. When you’re working on a new feature or bug fix, you’ll probably be modifying some of the existing code. This is where you should concentrate your efforts.

• If you come across some code you don’t understand, break it into pieces and rewrite it. This has the same effect on your comprehension as putting someone else’s complex thought into your own words.
• If it doesn’t have tests, write some! This is an excellent opportunity to make some assertions, then test them on the bit of code you’re working with.
• If there’s no style guide, work with your team to come up with one, or if you’re working alone, adopt a popular one. Limit your scope of updating the code to the style-guide guidelines to the immediate code that you’re working with.

2) Wrap it in tests

Chances are, you can understand a piece of code by reading through it, but do you grok it? Do you know what changes you can make without causing side effects? Sometimes these things aren’t as obvious as they may seem.

If tests already exist for the code, that’s a great place to start. When they exist, you can improve them and understand them better by adding additional test cases. This will increase your comprehension as well as improve the codebase overall.

If tests don’t exist, I suggest wrapping every piece of code you modify in tests. You might be surprised to find that the code does more than you think, or works differently than it appears that it should. Limit your scope of adding tests to the code you are working on.

3) Avoid playing the blame game

It’s easy to slide into the mindset that the developers who created the legacy codebase were sloppy or bad developers. The truth is, you probably don’t know what business constraints they were dealing with, you probably don’t have the specifications they were working from, and all (especially web development) programming methodologies evolve over time.

Remember, in the future someone may come back through your code and wonder these things, would it be fair to judge your coding efforts on future standards?