7FACTOR NEWS
7 Tips for Working Efficiently with Legacy Code
As engineers, we don’t often get much control over the coding environments we walk into. We can hope for clean, adaptable, tested code that allows us to quickly get spun up and start knocking out tickets. While this is the dream, our realities are usually more like holding your breath as you open up the hood, only to discover every engineer's favorite hurdle: legacy code.
Working with legacy code can be a confusing, convoluted setting where the best course of action isn’t inevitably apparent. To aid you in your journey, we’ve compiled a set of useful tips to help you efficiently and confidently tackle legacy code.
What is Legacy Code?
Pinning a specific definition on legacy code is difficult, as it can come in different shapes and sizes. Let’s go over some of its common characteristics:
- Most legacy code isn’t as ancient as it sounds. To put it simply, legacy code is code that is “outdated,” it doesn’t fit into an updated system, but its functionality is too fundamental to the program to abandon entirely.
- Legacy code has often lost support. There isn’t any plan for the code to be developed and expanded any further than what it already does. It serves its purpose and isn’t expected to do more.
- Inefficient code can also be legacy code. For instance, if someone developed a set of code but didn’t include tests within it to help explain what the code does, that counts as legacy code for our purposes.
- Lastly, in our examples, we have confusing code. This is the code that is important enough to the program as a whole that changing it at all is a little intimidating.
It’s important to include that legacy code isn’t necessarily code that was written by someone else. Old code that you wrote and no longer understand also fits into our criteria.
Now that we have the basics of what legacy code is, let’s explore how to best work with it.
1. Notes
Note-taking and referencing is something to pick up early on in the process of trying to improve your interactions with legacy code. Whenever you understand something new about the code or make a change, take note of it. Chances are that over time your observations can be pieced together to get a larger view of the puzzle.
As much as your own notes are important, try to access the notes of whoever originally wrote the code. While they may not always give the clearest picture on how the program was made functional, it could at least key you in on what functions tie into each other.
2. Teamwork
Even if you aren’t able to reach the original developer, getting others who may have worked with the system longer than you or simply have a different perspective than your own can help bring you to a better understanding of the issues you’re facing.
Getting too deep in your own understanding makes it difficult to see what others may have already picked up and can help you with.
3. Testing…
A great way to start to understand the legacy code you’re working with is to set up tests within it. See what parts cause it to run and figure out what’s just there as a safety net.
Once you know how it works, you can begin to adapt it and implement the changes and new features you need it to incorporate.
4. … Frequently
Once you do start changing the code, don’t default to assuming that whatever you implement is going to work flawlessly with what is currently there. You need to continue to run tests to ensure your code doesn’t break running features.
There may, after all, be some clashing happening between your new code and the existing code.
5. Adapting, not Rewriting
When working with legacy code, refrain from the impulse to rewrite the code (we know it’s hard). As enticing as it is to make something entirely new that does the work of the old program better than it did, it can be a waste of time and effort.
Additionally, there may be parts of the larger system that depend on the functionality of the legacy code, and rewriting it could lead to bigger problems than the legacy code itself is causing.
Working with legacy code is about getting things functional, not scrapping an already existing system.
6. Don’t Create Problems
What I mean here is to keep the code you are writing clean. It can be tempting to follow the style and mistakes of the legacy code for the sake of convenience, but keeping good coding etiquette while working on patching something can solve problems for the next set of developers that need to work with the legacy system.
If you’ve been following the other tips, then you’re already helping with that same problem! Keeping notes of what works and what doesn’t, implementing tests for the next person to utilize, and writing clean code are all things that solve more problems than they create.
7. Patience
Lastly, we have a simple tool: being patient. The more time you are able to spend with a set of legacy code, the better.
A lot of what makes legacy code difficult to work with is the point of view you take when working with it. Ultimately, the goal of working with legacy code is not to make it the simplest or most effective thing. The goal is to understand it enough to solve the problems it is giving you as best you can.
Moral of the story:
Working with legacy code is a CHALLENGE. In addition to utilizing these seven tips, remember to ask for help when needed and lean on your team! No good code was ever created in a vacuum. We wish you luck on all your current and future legacy code endeavors!