The 5 Best Tips For Working With Legacy Code & Software

As a developer, I hate working on legacy code and software, it's exhausting, the code is badly formatted and all over the place, typically, it'll take a lot longer than needed to even make a code change, even if it's a small system.

Working with legacy code can be a chore, but, since we don't throw away software every few months, it's a chore that's inevitable and has to be done by someone right?

That someone might be you.

This is why, I've put this article together to give you the 5 best tips for working with legacy code and software that'll hopefully make development a little easier.

Firstly...

What Is Legacy Code In Plain English?

Legacy code and software is the source code of a project or web application that's inherited from someone else from an older piece of that software. It's code that you don't really understand all too well and can't be changed easily.

It's built like building a house that you weren't involved in and now you've got to finish building the house since the contractor left, where do you start?

You could start by headbutting the wall of what's already been built, but that isn't going to get you very far at all.

Instead, you could just read the tips that I'm going to give you, and that will be the best starting point.

Why Does Legacy Code Exist?

As soon as a piece of code is written, and has been integrated and deployed to a production environment and used by whoever the intended users are, you could essentially refer to that code that was written, maybe just a few hours ago as being legacy code.

Especially if you're planning on rewriting it soon after getting an initial version of your feature finished.

Here's the thing, if we spent weeks upon weeks refining how a system works and ensuring every possible piece of functionality has been baked in, it would never go live.

As a business, the business would be spending weeks of your time developing a feature, that's so robust that in the end...

Never actually works as intended or underperforms.

Instead, it's best to get a MVP (Minimum Viable Product) out to market with the code that you've worked on, and then rewrite it once you've verified that your new feature works.

Often though, developers are forced to continue working on that MVP that it becomes the norm.

5 Tips For Working With Legacy Code

1. Test The Code - it's important to test the code you're working on for issues and unintended behaviour
2. Documentation - letting other developers know how to work on your project is vital, make sure to document the process as you're working through it
3. Refactor - you can opt to refactor or rewrite the legacy code you're working on, whichever makes sense, but think about it first
4. DRY - follow the DRY principle so that you're not repeating the code you're writing.
5. Research - researching new ways of implementing code might save you some time

Tip #1: Test The Code

It sounds so simple doesn't it, yet can take a long time, but sometimes it's worth it.

You need to be testing the code that you're working on, even if it's legacy code, it might not be working as the code owner initially once intended many years ago.

Testing is a critical part of any development process, whether that be when installing a boiler into your home, or building a bridge.

Tests are everywhere.

Sometimes it's a good idea to manually test the code to figure out the intended behaviour, and then consider setting up unit tests which will automatically test that piece of code each and every time you come to merge your changes to ensure that it's always working as intended.

Ensuring that tests are set up means that as the code becomes older and potentially more fragile, you'll always know exactly whether the code is working or not.

Tip #2: Documentation

Developers come and go, software is released and taken down, and ultimately, along the way, there should be some level of documentation to go alongside whatever has been written.

Sometimes, there isn't, and it can be an afterthought since everything the developer of the software has written is all locked away in his head.

Documenting how a system works, such as a web API is crucial...

• What are the available endpoints?
• How do I get a local environment set up?
• How do I deploy my changes?
• What about changing the database structure?

All of these are points that need to be documented, and the best place to do that as a developer is going to be the project's "readme" file as it allows for markdown for fancy code blocks and formatting.

Working with legacy code absolutely is going to require this type of documentation, so if you're inheriting some legacy code, it might be best to keep a log of what things do so that you're not confusing yourself or others.

Tip #3: Refactor Or Rewrite

I love the word "refactor", I'm not so keen on the word "rewrite" though, are you?

Do you know what the difference is?

Let me tell you...

• Refactor - typically means you're going to take a piece of code, and modify it to improve how it functions whilst persevering the original behaviour of the code
• Rewrite - this is where you're going to take the whole piece of code and start again, rewriting it in a more efficient way

It's often asked which one will be faster to complete by project managers, but speed might actually negatively affect how each of the methods work.

If a particular method technically takes less time, it may not be justifiable to even go down that route because it too will end up becoming legacy code more quickly.

I'd say in some circumstances, you're probably better rewriting a piece of code, but it can also make total sense to simply refactor too.

Tip #4: DRY (Don't Repeat Yourself)

When working with legacy code, it's often all too easy to fall into the habit of writing legacy code as much as it is to work with it.

This can often dig a hole deeper beneath you when you're loading up that new function that you've just written with hundreds of lines of code just because the legacy code you're working on has done the same.

If you're working with legacy code and software, try to at least implement the DRY principle wherever possible.

What does this mean?

Well, it means to not repeat yourself, and that can sometimes be difficult to do when working with older code.

Tip #5: Do Research

Since the time of the legacy code being written, chances are, if it's been a few months at the very least, there's going to be a new way of approaching a problem.

This might mean that the methods currently implemented into the legacy code can be swapped out with some helper functions for common functionality instead.

The only way you're going to figure this one out, is by taking some time to do some research, and that might be code research that you dedicate a specific amount of time for, or, you might choose to do it whilst you're working on refactoring some legacy code instead.

Whichever approach suits you, go with that.

Wrap Up

I hope you enjoyed this article, I'm sure over time I will be back to add more great tips into here since working with Legacy code can be exhausting sometimes.

If you enjoyed this article though, feel free to give it a share and don't forget to take a look at some of our other articles too.