Subtitle: An Agile Primer
Recommended to me by: Sam Livingston-Gray
While there was a lot of useful information in this book, I kept tripping over basic information presented in what struck me as condescending ways. It is possible to write for novices without assuming they are stupid.
I liked the extended example of planning a bicycle tour, complete with realistic details. It’s easier to read examples where I’m familiar with the domain and get the in-jokes.
I appreciated the emphasis on evaluating costs. If it costs a lot of time and money up front to design carefully, and those costs are never recouped, then the effort spent on design was not cost-effective.
Plan for future changes, but don’t try to anticipate them. Postpone decisions until you have more information, but isolate your assumptions to just one place in the code so you’ll be able to change them later.
The refactoring advice in this book seems targeted at small to medium-sized systems. She suggests that an inheritance hierarchy should be either deep or wide but not both, but does not offer alternatives for managing a system that doesn’t fit within those constraints.
When using inheritance, use hooks called from the parent class so that the child class does not have to call super in just the right way.
She advocates for composition over inheritance, using Forwardable to let an object respond to a contained object’s methods.
The patterns for reusing tests to match reused code look very useful. When you include a module in a class, include a test for that module in the test for the class. Test only the public interface of a class – its private methods are its own business. Test the state changes caused by incoming messages. Test outgoing commands with mocks of their recipients.
Recommended if you’re new to object-oriented design, or if you want to learn about some Ruby-specific design patterns, or if your coworkers quote heavily from this book.