Legacy is ‘inheritance’, and this inheritance is hard to deal with. Almost every developer has come through the project where the received code was written by someone else ten years ago. This is the inherited code — the historical code, which is often so terrible that it is not clear how to work with it. And if we get a legacy software in addition to the old code, we also have:
We need to deal with this and move on. And here, you can’t do without a good sense of humor – those who take life too seriously usually run away as soon as they see the real legacy.
What tasks will we have to solve while working with such a system? First, we will develop new functionality since it is alive, which means it is developing. Secondly, we will correct errors. And finally, although many people prefer to forget about it, we will optimize and stabilize the system, even if no one directly set such a task at the beginning of the project.
To be able to work with legacy software, we’ll have to use a lot of reverse engineering techniques.
First of all, you need to read the code carefully to figure out exactly how it works. This is necessary, as we most likely will not have sufficient documentation. If we do not understand the author’s train of thought and make changes, the consequences are unpredictable. To prevent them, you also need to delve into the adjacent code. And at the same time, move not only in breadth but also in-depth, digging to the very insides. Where is the error method called? Where does this code get it from?
Of course, you will have to spend a lot of time with the debugger – firstly, to find errors, and secondly, to understand how everything works – because the logic is obviously cannot be read by humans. Everything is debugged, including open source libraries.
When it comes to documentation, it is useful to resort to industrial archeology. It can be useful to dig up old documentation somewhere and talk to those who remember how the legacy code was written. Perhaps there is an old Confluence somewhere, probably at least a dump of its base, where you may find something. But often, there will be only documents that are not directly related to the code.
Using these techniques, sooner or later, you will begin to understand the code. But lest your efforts go to waste, you should be sure to document the results of your research. For this, we advise drawing flowcharts or sequence diagrams. You need to do this because without documentation in six months you will dig into this code like the first time. If it’s not you who is working with the code in six months, your followers will be very grateful for the available documentation.
You often need to prepare different documentation for yourself and for business. The reason is that your documentation is designed for engineers so business representatives will not understand anything. They need something clear that describes how the system works at the top level. Finally, don’t forget to use and read this documentation yourself.
So, let’s proceed to the dos and don’ts.
The most important thing here is not to rewrite the entire code again. Consider how many person-years it will take – the customer is unlikely to spend so much money on reworking what already works. This applies not only to the system as a whole but also to any part of it. Of course, you can get a week to figure everything out and another week to fix something. But they will hardly give two months to rewrite part of the system from scratch.
You should try to implement the new functionality in the same style as the rest code. In other words, if the code is old, you should not use new beautiful technologies – it will be complicated to read such code later.
Any task is primarily determined by business value. If you don’t prove the need for specific changes from a business point of view, these changes will not occur. You must try to take the customer’s place and understand their interests to convince them. In particular, if you want to refactor just because the code is hardly readable, you will not be allowed to do it, and you need to come to terms with it. You can reorganize the code step by step, smearing the work on business tickets. Or to convince the customer that it will reduce the time it takes to find errors and reduce costs.
Testing is necessary for any project. However, when working with legacy software, you should also pay special attention to testing since the impact of changes is not always predictable. You’ll need testers as much as developers. Otherwise, you should be incredibly good at automation.
When working with legacy software, it is important to establish everything related to DevOps and other practices that are not directly related to development. The good idea is to prescribe a specific release procedure, each step of which will be strictly documented. Only then the process becomes predictable and transparent for each of the participants.
The release procedure can be the following. When development finishes and phases of testing are completed, you contact DevOps. Then we discuss all the changes (we inform about all databases and configurations). If something goes wrong, the release rollback procedure is started.
The last stage is a code review. It is good practice if more than one person reviews each part of the code. Even in a powerful team, the code review process necessarily reveals some flaws. Sometimes the worst is found by the third or fourth reviewer. But to avoid excessive fanaticism, it is necessary to agree on how much review is enough to consider the feature ready.
Software migration is moving from using one operating environment to another, which is generally considered the best. Migration is the best option for legacy software. In this case, system migration allows companies to move to a new level of efficiency. The use of modern technologies will allow in the shortest possible time to scale legacy systems’ performance. Thanks to this, the technology will be supported for a long time, and it is much easier and cheaper than working with legacy code.
Migration of legacy systems offers a variety of benefits:
Products that are not worth migrating include, perhaps, some complex products that won’t be updated anymore and are used by a limited number of users. Then at the appropriate workplaces, you’ll have to use outdated versions of browsers that support Flash.
It may actually work with legacy software, but this is extremely short-sighted. If you have legacy system, we highly recommend migration to modern and actively developing technologies. And we even can assist you with that!
IntexSoft has a deep experience in migration, you can check our top articles on the topic:
Migration from Magento 1 to Magento 2
Migration from Flex to Angular / HTML5
The Best Practices For Migrating To A New CMS
If you are just about to migrate your legacy system, you’re welcome to contact us for a free consultation!
According to the Content Marketing Institute, only 16% of marketers indicate they have the right technology for the content management system (CMS) and are using it to its full potential.
There are four things you should know about legacy systems: they no longer receive service support, they are based on outdated technology, they are no longer available for purchase and they pose security risks.
If you work in a medium or a big company with a long history, there is a high probability that now you are dealing with some outdated legacy system. Many business owners suppose that it is okay to work with such systems as they still do their job.