How to deal with legacy code
Legacy code is a term used to describe software code which was developed before today’s technologies. The problems that are created by legacy code are many. For example, the software may be difficult to maintain and add new features because it was created without modern programming practices and standards. It may have been coded with poor quality. It may have been developed by a team that has little experience in coding. The reasons why legacy code exists are plentiful but what is more important is how you play out the cards that were dealt to you.
When it comes to legacy code, you need to decide whether or not you want to keep it around. The main problem with legacy code is that it doesn’t make sense anymore. The code was written many years ago. A new technology has come out and replaced the old one. In short, legacy code is a liability and there are two basic approaches to dealing with legacy code. You can either throw it away or you can try to fix it.
Trying to fix it
Legacy code is sometimes referred to as untested code that is used in production. In other words, it’s the section of the code that nobody wants to touch. In that case, writing tests should be your first step since tests are a safety net that will help you understand the code and make changes with confidence.
There’s a couple of schools of thoughts that advocate the right kind of test. Some believe that you should start with integration tests instead of unit tests because the tight coupling of dependencies makes it challenging to mock and isolate the code. Others believe that you should first identify change points and break dependencies to write a test. Whatever approach you take first, they should have one thing in common — recording the code’s current behavior and taking a snapshot of what it does.
When writing tests, you should take an iterative approach. This means that you can start by testing the most important functionality first and then gradually add more tests as needed. This can help to make sure that your tests are comprehensive and that they cover all of the important aspects of legacy code.
When the testing phase is done and you understand the behavior of legacy code, start refactoring in small steps. Make small, incremental changes. These small changes will be easier to review and will be less likely to introduce errors. If you are unsure about a refactor, leave the code as is. It is better to have code that is not perfect than code that is broken. What is worth bearing in mind is that you shouldn’t change the behavior of code but only its design.
Rewrite legacy code from scratch
The good news is that legacy software can be rewritten and modified. You know the flaws of the old system and its design shortcomings so you pretty much know what to do. However, the drawback is that while working on the new system, you’ll have to keep the old one running. Even if legacy code is in a maintainable condition, there will still be bugs to fix in code or some client’s request for the legacy system.
Allocating all the resources to the task of coding a new system that would work in the same way as the old one may be a tall order. It may be difficult to convince the leaders of your organization to shut down the ongoing support for customers and let them wait 6 months for an improvement while all the engineers are working on coding the new system.
Rewriting appeals because it offers the chance to outperform the outdated system by avoiding its flaws. But before you take on this task, you must thoroughly assess the scenario. Ask yourself the question if you have the means necessary to keep both systems running and if things would really improve that much.
Rewriting is not always the safest or most efficient course of action. Code restructuring can help you improve maintainability and performance quickly while also allowing you to start fresh with new steps in your product development cycle.
Conclusion
The decision of whether or not to keep legacy code is a difficult one. You will need to weigh the pros and cons of each option. If you decide to keep the code, you will need to make sure that you can fix it by refactoring. If you decide to throw it away, you won’t have to worry about it anymore but you will have to deliver a new system.
