I was introduced to this term at a meeting about a new project, and it has been said many times since. It is a simple phrase that perfectly states the way I feel about my job as a software engineer.
A few years ago, I was introduced to the idea of evolutionary architectures in Reflexive Loops, by Neal Ford and others. The book is an excellent read for anyone who needs to look at their code from a fresh perspective, and I recommend it highly.
The book also teaches you that if your system is well designed, you can always add new features and delete old ones with ease; you never need to rewrite your code (unless you want to).
I have found that this idea applies to our ideas as well. We do not need “big ideas” to make our systems better; we just have to keep the best ones and discard the rest.
Legacy code is simply code without test.
Legacy code is simply code without tests. Much of it was written before the age of agile development, unit testing, and Test Driven Development (TDD). Legacy code often does not have automated tests, and this makes it hard to change.
The problems with legacy code are well known. For example, software suffers from:
Poorly written code
Complexity
Technical debt
No tests or low coverage
But legacy software doesn’t have to be a burden. It can be a blessing. Legacy code is your organization’s knowledge base and your company’s competitive advantage. We should not discard good working software; we should keep the best parts and replace the rest with modern, tested software.
Legacy code is a term for code that has been in production for a while and has since accumulated subtle bugs, confusing complexity, and inconsistencies. It provides the critical functionality that has made all the money for the company so far, but nobody dares to change it.
It is notoriously hard to work with legacy code: adding new functionality is slow and frustrating. But it can be done! I’ve developed a set of techniques that allow me to change even the most tangled legacy code into clean, well-structured software. And I want to share these techniques with you.
In this blog I’ll be writing about refactoring legacy code: how to identify problems and turn them into clean, well-structured software.
One of the problems with the term “legacy code” is that it’s poorly defined. It’s not a technical term like “polymorphism”. It means different things to different people.
I have my own definition, and I’ll share it with you now: legacy code is simply code without tests.
I don’t care how well-written it is. I don’t care how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our changes will be improvements or not.
If you want to understand legacy code, the first thing to know is that you’re going to need tests. Not just unit tests in the strictest sense, but integration tests, customer tests, manual tests—whatever it takes to gain confidence in your changes. Without those kinds of tests, there’s no way for you to work with the code confidently.
Legacy code is code without tests.
Tests are what make it possible for us to change software. If we don’t know whether a change will break something, we cannot make that change. If we cannot make changes, the software will eventually become so cumbersome and cumbersome to use that it loses its value.
If you’re working on a project that doesn’t have automated tests, I hope you’ll consider adding them. Over time, this will help your team maintain their sanity and keep the code working after each change.
A man walks into a bar and says to the bartender, “I’ll have a beer. Oh, and by the way, check out my code.” He pulls his laptop out of his bag, fires it up, and shows the bartender what he’s working on. The bartender looks at it for a moment and then says, “Oh yeah! I can see where that would crash in IE6.”
You’re not a real developer until you’ve shown your code to a stranger in a bar.