There are many reasons that legacy code exists. It’s a part of the software development process. Some of the most common reasons for legacy code are:
The product is successful and it’s time to add some new features to it.
The developers left the company, or they were moved to another project, or they were hired by another company.
Bugs in the code were discovered and need to be fixed immediately.
In this blog I’ll try to discuss different ways of working with legacy code and how can we fix it without breaking anything.
What do you think of when you hear the term ‘Legacy Code’? Is it a mountain of spaghetti code? Is it thousands of lines long, with no comments and no tests? Does it have a terrible design, which makes it impossible to understand?
It is likely that you would use a combination of these definitions or even more. The point is that legacy code has different meanings for different people. There is no universally accepted definition. So, why do we use the term legacy code?
Let’s take a look at the process that leads to legacy systems. It usually starts out with a new project, where one team builds a system from scratch and uses the latest technologies and frameworks available at the time. At this point everything looks great: everyone is happy, coding away and things are moving forward in what seems to be the right direction. Then some years forward, new technologies and frameworks get released and become widely adopted. This leaves the original system behind, not taking advantage of improvements introduced by newer versions of languages or libraries. The system starts aging; it becomes harder to change and also harder to maintain – this is what we call technical debt. This is only one way to create legacy code though, there are many more paths that lead to this situation.
The Legacy Code Blog has been created as a means to centralize the conversation around legacy code.
The blog will cover topics such as:
– What is legacy code?
– Why do we have legacy code?
– How do we deal with legacy code?
– What are some of the common problems encountered with legacy code?
– What can you do to prevent your code from being legacy?
What is legacy code?
Legacy code is a programmer’s way of describing the nastiness that we have to deal with on a daily basis in the software industry. It’s old code that someone else wrote, and no one dares touch it for fear of breaking something. You probably know exactly what I’m talking about.
The Problem
Legacy code is everywhere! Heck, as you are reading this, there are probably several bugs waiting to be found in the code that makes up this website. Just think about all the old systems out there running businesses. Most of these systems were written years ago by programmers with less experience than you currently have. These systems are built with languages like COBOL, PL/1 and RPG (I kid you not). Although these languages may be antiquated, the business logic that they contain is still valid today. So even though we may not actively write programs using those languages anymore, we still need to maintain them.
The Solution – Unit Testing
Unit tests are small automated tests that ensure that individual pieces of our applications work as expected. They can help us prevent future bugs from creeping into our application while at the same time providing documentation on how our application works.
“Legacy Code” is a term that gets thrown around a lot in software development. It sometimes refers to an old application and other times to an application which was quickly slapped together. In my opinion, Legacy Code is code which has been in production for a long period of time, has gone through many changes, and has no unit tests. The lack of unit tests is the real killer and the biggest problem.
The reasons behind creating Legacy Code are:
– Client requirements change over time.
– Developers don’t have enough knowledge or experience on a certain platform or technology.
– Lack of planning before starting a project.
– Lack of technical leadership by the team’s lead/manager.
– Lack of testing and quality assurance.
In computer programming, legacy code is source code that relates to a no-longer supported or manufactured operating system or other computer technology.
As software ages, the technologies on which it relies may become obsolete and unsupported, making it increasingly difficult to repair bugs, add features or port the software to new hardware or operating systems. Sometimes this is because the vendor no longer exists; in other cases, changes in market conditions have led to the product being superseded by newer technology.
Legacy code is, quite simply, source code that is not covered by automated tests. It’s code written by someone who either didn’t know about testing or was too lazy to bother.
The more legacy code you have, the harder it becomes to make changes because you don’t know if you broke something. And as we all know, software is never finished. Sooner or later you have to go back and make a change.
You can’t fix everything in one go. But you can start small and make your way through the codebase. If you’re the only programmer on a project, it’s your responsibility to deal with the legacy code. It won’t fix itself and no one else will do it for you.
It will be hard at first but once you get used to it, it’ll become second nature to write tests for your new classes and functions as well as for any legacy code you touch. Soon enough you’ll see a significant drop in the number of bugs being reported because most errors occur during refactoring when changing existing functionality (or fixing bugs). Tests help prevent those errors from making it into production and give you peace of mind when making even the smallest changes.