Legacy code - What is it and how to work with it?

Programmers in their working career often encounter the term legacy code. Many people understand it as inherited code, but in fact this term may have various meanings. Nonetheless in most cases it brings negative associations and evokes general scepticism and discontent in people who have to work with it. Below we’ll explain what legacy code actually is and why it has such a bad reputation within the IT environment.

One of the most popular definitions of legacy code is the one that states that it’s code which hasn't been tested. For this reason we can’t tell how it really works and what the possible schemes of its action are and in result we don’t know how to change it. Next definition explains that legacy code is code which could have been tested, but in an incorrect way, so it’s as difficult to use as not tested code. In turn some define legacy code as obsolete code, which because of the lack of modern solutions doesn’t fit to current technologies and it’s hard to adjust it. Others generalise this term and use it to name each code, which is incomprehensible and burdensome to modify. It’s always harder to work with code that we didn’t create from the beginning. Of course we can think that the best solution is to rewrite the code anew, but usually it’s not the best option. If we don’t know the system and the way it works, we should deeply consider this decision, because it may appear totally unprofitable. How to competently approach work with legacy code, so it won’t associate with unpleasant duty, but interesting experience?

The approach to work with the code is very substantial. If from the start we are demotivated and we acknowledge that it’s a hard and tedious job, for sure it'll be like this. It’s not worth wasting time on pondering how someone could make so many mistakes in the code. Most often we don’t know the whole history of the code, especially if it was written by several people. This is the biggest challenge in working with legacy code - to discover step by step the dependents, which at the first glance aren’t so obvious. Even if sometimes it's a monotonous job, it also has its good sides. It allows us to come back to the basics of programming, like writing clear code, using good practices or correct testing. Apart from the knowledge and skills, working with legacy code isn’t a job that can be done immediately. In contrast it demands strong focus on and taking steps, which omission will make you come back to the starting point.

The first crucial step that we need to take is familiarising with documentation (if it’s available). If we learn initial assumptions of the project, maybe we’ll be able to better understand the current structure and the main idea of the code and its author. Secondly, we shouldn’t rewrite too much code at once, because it may appear that rewriting the code will cause new mistakes and destroy essential conjunctions, which haven’t been discovered yet. Instead of rewriting the code it’s much better to conduct refactorization (change the structure of the code without changing its functionalities). It’s good to refactorize the code gradually, implementing too many changes at once can make needless confusion. Moreover remember to make changes only when necessary. Just because you think that the code is completely incorrect and misfitted to current standards, it doesn’t mean that it’s absolutely wrong. This is why you should delve into the code’s structure and analyse, which elements can be transformed and which should be left uninterrupted.

There’s no point to assume that working with legacy code is a hard and elaborate process. It’s definitely better to treat it as a puzzle, in which connecting subsequent elements gives great satisfaction and the whole process of bringing those pieces together teaches patience, endurance and doing precise tests. Taking into consideration that each code will someday become to some extent legacy code, the majority of people who deal with programming won’t miss such lessons.