The best idea in this book for me was the newspaper metaphor that is mentioned with regards to formatting your code. This describes the idea of making code read like a newspaper article. We should be able to get a general idea of how it works near the top of the class before reading more and more details further down. This can be achieved by breaking the code out into lots of small methods. It was strange how involved I got with the newspaper metaphor. Having read about it early on I started looking at all code after that to be in that format and when it wasn’t (when showing examples of not such clean code) I became disappointed.

Learning Tests - the idea of writing tests to gain understanding of how a 3rd party code works - was an idea I had not come across before. The idea here is to write simple tests which describe the way that you think a 3rd party library works for example. If a new version of the library is released we can rerun these to check that it still works the same way. Previously I have always written throwaway pieces of code to gain this understanding but writing tests that we can later refer back to is a much better way of achieving the same aim.

Treating the test code as being as important as the actual code was another idea that came across. Writing expressive tests is something that I am very interested in, and my colleague Phillip Calcado has written about the idea of Domain Driven Tests. Uncle Bob mentions a similar idea which he refers to as a Domain Specific Testing Language - a set of functions and utilities to help derive a testing API. The same ideas about keeping the tests expressive and clutter free apply. To end on a quote which is oh so true

I came out with an improved understanding of how the Open Closed Principle, Single Responsibility Principle and Law of Demeter can be adhered to in a code base. The examples used in the book are very like code I have seen on projects so it was much easier to relate to. I found the context they were presented in in this book made them much easier to understand as it was part of a bigger picture of writing clean objects rather than just addressing the ideas in a standalone fashion.

One of my favourite quotes from the book is the following

I really liked the approach used in the case studies used in the last three chapters of the book. The code was presented, the problem with it identified, a solution proposed (and it’s name referenced) and then the implementation was detailed. It reminded me of the approach taken in Joshua Kerievsky’s Refactoring to Patterns in its pragmatic approach to aiding learning. I found it useful to refer to Chapter 17 'Smells and Heuristics' when reading the case studies to check exactly what the smell/heuristic was describing. A reference (e.g. G30) is given in brackets after the paragraph which describes how to improve the code.