A decent turn out at the Lamb and Flag to discuss “Refactoring to Patterns” by Joshua Kerievsky. I was joined by Tom, Mick, Steven, Andy, Ursula and John.

We started out by discussing what Steven thought of the book, because he’d previously said that he wasn’t impressed by it. He explained that he’d found the books “Refactoring” and “Design Patterns” to be life-changing. When he heard about this book, he expected it to be in the same mould and ordered it before it was even published. But when it arrived it didn’t live up to the expectation. However, having looked at it again, he has now come to the conclusion that it does what it says on the tin. So it is a useful book after all.

We all agreed that it isn’t a book for dipping into. You need to concentrate on it and read a whole pattern in a single sitting. I found that it was not good for reading just before going to sleep. You think “I’ll have a quick read before turning out the light”, pick it up and start reading “Replace Composite with Polymorphic..” and don’t get much further.

I think it is a book to work through with colleagues, finding places to apply the patterns and seeing how the design turns out. Tom agreed and said that he liked to read the book in a different order to that given. He thought the best way was to ‘follow the smell’ and see how each smell could be removed by application of the refactoring.

Mick showed us his copy of the book, complete with many markers. He’d found lots of places in his current codebase where these refactorings would help. He thought that the main ‘take home message’ was that sometimes adding functionality the naive way and refactoring was better than trying to think of the perfect solution upfront. He also said that he had found some of the “Benefits and Liabilities” sections to be irritating because initially all of the liabilities seemed to be “it could be too complicated”. Later on he thought that the liabilities became more interesting.

Ursula said she thought it was like a travel guide. I liked this analogy. The section at the front is like the background information on the country and each refactoring is a different place. If you’re visiting a particular place, then the section in question could be very useful, if you’re not, then it isn’t going to be so interesting to read.

John said he found it very much focussed on object-oriented programming, which was not quite what he was expecting. This was mainly because “Design Patterns”, although strongly focussed on object-orientation, is about higher level design ideas. So you can get something out of it, even if you’re not working in OO. But this book is all about the nuts and bolts of working in an OO language. Since he has only dabbled in OO, he didn’t follow the book through.

There was some discussion about how or if you could automate some of the refactoring in this book. Mick mentioned Google’s “Singleton Detector” and I mentioned that I’d attended a half-day tutorial with the author, Joshua Kerievsky in which he’d given us some material that he’d developed while writing this book. It was called (slightly confusingly) “Patterns of Refactoring” because it described techniques he’d come up with while writing these patterns. These techniques came out of the constant improvements to the refactoring steps described. Quite often the first draft would leave the code broken and untestable for a long period. But over time he found ways to make small steps that kept the compiler and the test suite happy. Typically, I forgot to bring these notes with me, but there is a short article I wrote about it on the company blog.

This led Ursula to ask about how testing and refactoring fit together. There were some differing views. If you are doing small scale refactoring, then the tests will likely not need changing and are a good indication that nothing has been broken. With large scale refactoring, the tests are liable to need changing as you go along. In that case, it is helpful to have some higher level functional tests as backup to show that all is still well.

We then moved onto a discussion of how deprecation fits into the picture, particularly when doing refactoring in very large systems and where published interfaces are involved. Ursula described a system whereby a feature was scheduled to be removed at a given release and how this simplified matters.

Finally, we talked about my idea of alternating the discussion month by month between an agile book and a programming language. When I explained that it was more likely to be an older language (like Smalltalk or Lisp) or a more esoteric one (like Haskell or OCaml) there was more interest in the idea. Steven said he didn’t want to end up discussing PHP or the like. So it seemed like there was actually more enthusiasm than I thought for the idea….