Genre: Best Practices
GOOS is probably the most hyped programming book I’ve ever heard about. Maybe that’s just my social circles, or maybe it’s a genuine reflection of how good the book is. Regardless, I snapped myself up a copy to see what all the fuss was about.
As an added bonus, the book promises to be filled with insights into object-oriented programming from two agile developers who have worked on an extensive catalogue projects including telecoms, finance and sports.
A beginner’s education in TDD and its benefits kicks off the book - clearly aiming it at developers who may or may not be familiar with TDD. There is also talk of rapid feedback cycles, gaining insight and improving the code – the agile perspective. Part 1 of the book even has a section on CRC cards.
All of part 1, in fact, is an explanation of the tools and concepts. The tools are Java, JUnit, Hamcrest, and as-mentioned, the concepts are testing, OO, agile development.
You may be familiar with the term walking skeleton, which comes from part 1 of this book. This concept encourages you to get a minimal amount your application working end-to-end with all dependencies (including web server). It’s a smart concept, and typifies some of the excellent insights in the first part of the book
Part 2 is hands on. The authors are creating an application that bids on auctions using the development process they hyped-up in the first part – lot’s of requirements, early feedback, end-to-end tests that drive out the unit tests and tonnes of refactoring.
I think it is brilliant how the authors advocate leaving a few design smells stinking the code base out. As the application is developed, the smells are gradually deodorised and refactored away. The rationale for keeping them around is to understand where changes are occurring and see how other parts of the design evolve that may better incorporate a clean-up of these smells.
My biggest disappointment is keeping up with this section of the book. When refactoring occurs, the old code is not always in-situ for a quick comparison. This left me not fully understanding some of the design decisions.
The concluding part of the book is a few chapters on dealing with specific types of testing – asynchronous, threading and persistence. I haven’t used any of these techniques personally but they are good to know about.
Not quite worthy of the all the hype but an excellent read for any serious developer. GOOS excels not just at teaching the authors’ style of TDD, but how to fit TDD into an outside-in software development process with short feedback loops that maintains a high-level of code quality – allowing the addition of regression-free features at a solid pace.
Alas, I wasn’t too chuffed with how they wanted me to abstract my database so far away that persistence wasn’t even slightly-obvious in the code. I also wasn’t happy with trying to keep up with all the refactoring in part 2.
In spite of those two criticisms, of which one is an opinion, I would definitely encourage devs of any skill level to check out this book. If you don’t know anything about TDD or agile, this book might be exactly what your career needs.