Changing code with out tests is like doing aerial gymnastics without a net.
What is legacy code?
Let's look at the strict definition: Legacy code is code that we've gotten from someone else. Maybe our company acquired code from another company; maybe people on the original team moved on to other projects. Legacy code is somebody else's code. But in programmer-speak, the term means much more than that. The term legacy code has taken on more shades of meaning and more weight over time.
What do you think about when you hear the term legacy code? If you are at all like me, you think of tangled, unintelligible structure, code that you have to change but don't really understand. You think of sleepless nights trying to add in features that should be easy to add, and you think of demoralization, the sense that everyone on the team is so sick of a code base that it seems beyond care, the sort of code that you just wish would die. Part of you feels bad for even thinking about making it better. It seems unworthy of your efforts. That definition of legacy code has nothing to do with who wrote it. Code can degrade in many ways, and many of them have nothing to do with whether the code came from another team.
In the industry, legacy code is often used as a slang term for difficult-to-change code that we don't understand. But over years of working with teams, helping them get past serious code problems, I've arrived at a different definition.
To me, legacy code is simply code without tests. I've gotten some grief for this definition. What do tests have to do with whether code is bad? To me, the answer is straightforward, and it is a point that I elaborate throughout the book:
Code without tests is bad code. It doesn't matter how well written it is; it doesn't matter 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 code is getting better or worse.
You might think that this is severe. What about clean code? If a code base is very clean and well structured, isn't that enough? Well, make no mistake. I love clean code. I love it more than most people I know, but while clean code is good, it's not enough. Teams take serious chances when they try to make large changes without tests. It is like doing aerial gymnastics without a net.
Recommend the below book for more understanding on how to deal with legacy code.
Working Effectively with Legacy Code (Get Better Performance Out of Your Legacy Systems): Is your code easy to change? Can you get nearly instantaneous feedback when you do change it? Do you understand it? If the answer to any of these questions is no, you have legacy code, and it is draining time and money away from your development efforts. Michael Feathers offers start-to-finish strategies for working more effectively with large, untested legacy code bases.
Other useful books from the same publisher:
Clean Code (A Handbook of Agile Software Craftsmanship): Best agile practices of cleaning code “on the fly” that will instill within you the values of a software craftsman and make you a better programmer—but only if you work at it.
Clean Coder (Practical Advice for the Professional Programmer): Robert C. Martin introduces the disciplines, techniques, tools, and practices of true software craftsmanship. This book is packed with practical advice–about everything from estimating and coding to refactoring and testing.
Clean Architecture (A Craftsman's Guide to Software Structure and Design): Uncle Bob presents the universal rules of software architecture that will help you dramatically improve developer productivity throughout the life of any software system.
The Software Craftsman (Professionalism, Pragmatism, Pride): Sandro Mancuso helped found the world’s largest organization of software craftsmen; now, he shares what he’s learned through inspiring examples and pragmatic advice you can use in your company, your projects, and your career.
Whats your take on Legacy Code and tests? Feel free to share your thoughts in comments below.
What is legacy code?
Let's look at the strict definition: Legacy code is code that we've gotten from someone else. Maybe our company acquired code from another company; maybe people on the original team moved on to other projects. Legacy code is somebody else's code. But in programmer-speak, the term means much more than that. The term legacy code has taken on more shades of meaning and more weight over time.
What do you think about when you hear the term legacy code? If you are at all like me, you think of tangled, unintelligible structure, code that you have to change but don't really understand. You think of sleepless nights trying to add in features that should be easy to add, and you think of demoralization, the sense that everyone on the team is so sick of a code base that it seems beyond care, the sort of code that you just wish would die. Part of you feels bad for even thinking about making it better. It seems unworthy of your efforts. That definition of legacy code has nothing to do with who wrote it. Code can degrade in many ways, and many of them have nothing to do with whether the code came from another team.
In the industry, legacy code is often used as a slang term for difficult-to-change code that we don't understand. But over years of working with teams, helping them get past serious code problems, I've arrived at a different definition.
To me, legacy code is simply code without tests. I've gotten some grief for this definition. What do tests have to do with whether code is bad? To me, the answer is straightforward, and it is a point that I elaborate throughout the book:
Code without tests is bad code. It doesn't matter how well written it is; it doesn't matter 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 code is getting better or worse.
You might think that this is severe. What about clean code? If a code base is very clean and well structured, isn't that enough? Well, make no mistake. I love clean code. I love it more than most people I know, but while clean code is good, it's not enough. Teams take serious chances when they try to make large changes without tests. It is like doing aerial gymnastics without a net.
Recommend the below book for more understanding on how to deal with legacy code.
Working Effectively with Legacy Code (Get Better Performance Out of Your Legacy Systems): Is your code easy to change? Can you get nearly instantaneous feedback when you do change it? Do you understand it? If the answer to any of these questions is no, you have legacy code, and it is draining time and money away from your development efforts. Michael Feathers offers start-to-finish strategies for working more effectively with large, untested legacy code bases.
Other useful books from the same publisher:
Clean Code (A Handbook of Agile Software Craftsmanship): Best agile practices of cleaning code “on the fly” that will instill within you the values of a software craftsman and make you a better programmer—but only if you work at it.
Clean Coder (Practical Advice for the Professional Programmer): Robert C. Martin introduces the disciplines, techniques, tools, and practices of true software craftsmanship. This book is packed with practical advice–about everything from estimating and coding to refactoring and testing.
Clean Architecture (A Craftsman's Guide to Software Structure and Design): Uncle Bob presents the universal rules of software architecture that will help you dramatically improve developer productivity throughout the life of any software system.
The Software Craftsman (Professionalism, Pragmatism, Pride): Sandro Mancuso helped found the world’s largest organization of software craftsmen; now, he shares what he’s learned through inspiring examples and pragmatic advice you can use in your company, your projects, and your career.
Whats your take on Legacy Code and tests? Feel free to share your thoughts in comments below.
Comments
Post a Comment