How to deal with legacy code
As developers, we often have to work with old code that we’ve inherited from someone else. Of course, it’s the nature of technology to change over time, so we periodically need to make updates. But it’s not necessarily the changes in technology that make legacy code difficult to deal with.
I have worked with very, very old code bases and have also experienced some migration operations. My last experience was migrating a PHP 5.3 project to a PHP 7+ version. It was a great experience for me.
I’d like to talk a little bit about the migration process and also how we can prevent future migration processes by writing clean code.
What is legacy code?
Is any old code considered legacy? Absolutely not. Here are a few good definitions:
Legacy code is code that you need to change and that you struggle to understand.Code written by someone else (usually someone no longer available for any contact) that you must now deal with.
Code that is usually not easily rewritten because of dependencies on that code.
I would make some additions to these definitions. In most legacy code, you will find some magic. Generally, legacy code still works, but it is very hard to add new features to it. Sometimes only a few developers understand how the code actually works.
Added to that, legacy code generally has a lot of bugs, and it’s hard to find the actual problem to fix it. Mostly, the code is not clear enough to understand.
How to deal with it
There are few ways to live with legacy code.
If you love challenges, the best thing to do is to rewrite the project with new technologies.
This is the best option in my opinion. But this option has some cons, of course. To rewrite existing legacy code, you need to know all the features of your product.
Also, if you are working in a live system, you need to maintain two codebases at the same time, and you can possibly duplicate some features.
In our product, we give 24–7 support and we work with zero downtime. We don’t have the option of using maintenance mode or scheduled maintenance. This is another condition that makes the migration process difficult.
Living with existing code is hard
If you are not able to rewrite or migrate existing legacy projects, you need to find ways to add some new features to your product.
Current developers that are working on the project must take on some additional responsibilities.
With legacy code, it’s easier to make mistakes. Developers need to be careful and must check all existing dependencies and usages in the codebase.
When adding new features, you need to be OK with some hacky solutions. Generally, people look at hacky solutions as bad, but I don’t exactly agree with this. In legacy projects, generating hacky and fast solutions is a lifesaver. Understanding legacy code generally takes a long time.
Profile your application whenever you can
Measure the problems, add some breakpoints, and check the timings always. This allows you to improve the current legacy code and your application performance.
By profiling just existing queries, I improved the page performance by 17x with the same technology and the same database.
Don’t break your application with basic features
I said that adding new features is hard for legacy projects. While some well-considered new features are OK, if a new feature could possibly break your app, don’t add it. Sometimes you need to know to say no.
In the next article, I will cover how to write clean code to prevent your code from becoming legacy code in the future.
Twitter: https://twitter.com/atakde
Github: https://github.com/atakde
If you like to get more updates from me,
please follow me on Medium and subscribe to email alert.
