We’ve got a bit of a book club going at work, and this was the first read. We were inspired to read it by a conference talk she gave, where she went through the Gilded Rose kata and very clearly demonstrated the joys of refactoring well-tested code. Metz is a great communicator, and I highly recommend that talk as an entry point to her work.
This book, referred to as “POODR”, continues in the same style of “here’s some techniques you can use to write better code.” And, for the most part, it’s an excellent resource in that regard! Frankly, my only issues with it come down to Ruby not being my taste in languages, and it’s not as if I went into the book not knowing that it’d be in Ruby.
The largest chapter is on writing tests; compared to the rest, it looks rather intimidating. That said, I wound up skimming a lot of it—despite the assertion, earlier in the book, that type systems just add overhead and slow developers down, the majority of the chapter on testing is devoted to writing tests that… ensure you’ve got a type system. I remain unsold on these untyped/duck-typed languages; over here in Swift, I get all those unit tests for free, and the compiler forces me to run them every time I try to build. The time I spend writing tests is entirely spent writing tests for the business logic, not on making sure that I forgot a required method in a subclass.
Duck-typing also requires more faith in your fellow programmer—or even your future self—than I actually have. There’s a great description in the book of implicit object hierarchies, which struck me as being a beautiful academic concept, but will fall apart the moment the project gets larger than “a single developer, working on it continuously.” Add another developer, and they then have to read through the entire codebase to be sure they’ve got enough information to grasp those implicit types; take a break for a month, and you’ve got to reread it all to get back to the same place. And there’s no guarantee that the reading of everything will get you back to the same mindset that you had earlier, so those implicit types fall part pretty quickly. If you want to communicate an idea like that, you have to write it down—and why bother writing a comment when you can write that mental model into the code itself, and have the compiler check that it’s still being followed?
Don’t get me wrong, as I sit here writing only the things I didn’t like about the book. On the whole, I greatly enjoyed it, and found it full of useful ideas! It’s simply the way of human brains to engage more when we disagree than when we agree.
So, if you’re someone who spends time writing code, I do highly recommend this book. Just, y’know, keep in mind that it says Ruby on the cover, and Ruby has opinions about a few things that you may not agree with. You can get the book from its website, or if you (or your employer) have an O’Reilly subscription, it should be available in that library.