Liked It“Michael Feathers defines legacy code as “Code without tests”. Based on that definition, do you work on legacy code? Probably almost every programmer gets confronted with parts of code not covered by Unit Tests. Do you want better techniques to work with code that doesn’t have tests? |
“Michael Feathers defines legacy code as “Code without tests”. Based on that definition, do you work on legacy code? Probably almost every programmer gets confronted with parts of code not covered by Unit Tests. Do you want better techniques to work with code that doesn’t have tests?
If you take up the challenge of reading and applying this book, you’ll learn several specific techniques that you can employ to take this code, make the absolute minimum number of modifications to get the code testable. Then you’ll feel safer applying your usual refactoring techniques or doing the changes you need to make.
Example titles in this book are “This class is Too Big and I don't want it to get any bigger”, or “I need to change a monster method and I can't write tests for it”. Who hasn't encountered these problems? In these and other chapters, Michael practices several dependency breaking techniques.
Other chapters show how to write tests that help you understand the current behavior. Other chapters include handy techniques for understanding code, such as Telling a Story, Effect Sketching, Scratch Refactoring and Telling a Story.
I use this book when I inherit a set of code that just doesn’t have any tests, and I have to make changes to it. If you find yourself staring at blocks uncomprehensible code, you should do the same.”
“This book from Michael C. Feathers came at a perfect moment in my software developer's life, as I started to read it right before I came to work on a legacy monstrosity.
The book is well organized, easy to ready and full of practical guidelines and best practices for taming the legacy codebases that are lurking out there.
I really appreciated Michael's definition of legacy code: for him "it is simply code without tests". And, indeed, untested code is both the cause and the characteristic of legacy code.
Near the end of the book, Michael has written a short chapter titled "We feel overwhelmed" that I have found encouraging and inspiring. Yes, working with legacy code can actually be fun if you look at it on the right side. My experience in this domain is that increasing test coverage is elating, deleting dead code and inane comments is bliss and seeing design emerge where only chaos existed is ecstatic.
Conclusion: read this book if you are dealing with today's legacy code or if you do not want to build tomorrow's.”