Author: Michael Feathers Publishing/Release Date: September 1, 2004 Link: https://www.amazon.com.au/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
Preface
Feathers’ working definition: legacy code is simply code without tests. What do tests have to do with whether code is “bad”? His answer, elaborated 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.
That sounds severe. Isn’t clean, well-structured code enough on its own? Clean code is valuable, but it isn’t enough — a team that changes code without tests is doing aerial gymnastics without a net.
To keep change safe, you have to be able to answer three questions:
- What changes do we have to make?
- How will we know we’ve done them correctly?
- How will we know we haven’t broken anything?
If change is risky, you can’t afford much of it — so risky code tends to ossify.
The cost of avoiding change
In a good system, you feel calm and confident once you’ve understood the code well enough to change it. In a poorly structured one, going from “figuring it out” to “actually changing it” feels like jumping off a cliff to escape a tiger: you hesitate, then change it only because you have no choice.
Avoiding change has knock-on costs:
- You get rusty. Skills like splitting a big class into pieces only become routine if you do them regularly. Do them often and you get better at predicting what can and can’t break.
- Fear builds up. Many teams live with a growing dread of change without realising how much fear they carry — until they learn better techniques and it starts to fade.
The naive alternative — “just try harder,” add more people, scrutinise everything, do it the “right way” — doesn’t actually make change safer, and you still have no way to know whether you got it right. Tests are what give you that feedback.
Chapter 2: Working with Feedback
Chapter 3: Sensing and Separation
Chapter 6: I Don’t Have Much Time and I Have to Change It
Chapter 7: It Takes Forever to Make a Change
Chapter 8: How Do I Add a Feature?
Chapter 9: I Can’t Get This Class into a Test Harness
Chapter 10: I Can’t Run This Method in a Test Harness
Chapter 11: I Need to Make a Change. What Methods Should I Test?