<aside> 💡 These are my personal notes taken when reading the book. I wrote a blog post to highlight the salient points of the book:
The key points of Working Effectively with Legacy Code
</aside>
Without tests, it takes a long time to understand what the code does. And it's painful to change.
Avoid littering direct calls to library classes in your code. You might think that you'll never change them, but that can become a self-fulfilling prophecy.
<aside> 💡 This definition is useful, well-known, and true most of the time. However, I have worked with tested code that was still painful to change. Thus, I prefer one that is slightly different: Legacy Code is valuable code you’re afraid to change.
I wrote about this with more details here:
What is Legacy Code? Is it code without tests?
</aside>
A test is not unit if:
I like that definition of “unit” tests because it focuses on what matters: the speed and reliability of the feedback loop. We don’t get caught into semantics of what makes a “unit”. See this great article from Martin Fowler about The Fantastical Shapes of Testing.
https://twitter.com/searls/status/1393385209089990659?s=20&t=XCvTOqq3Kjs7UUeyfgk3uA
Add tests. Then refactor. Then implement the new feature.
Delete unused code.
When code is only glue code between an input (e.g. CLI) and 3rd party systems (e.g. API calls), identify and separate the different responsibilities: