We met in the “Far from the Madding Crowd” pub in Central Oxford. Since we weren’t quite sure who was who it took a few minutes for us to find our fellow Oxtremists. The copy of “Refactoring” lying on our table was the giveaway. We sat in the slightly quieter non-smoking section on the left hand side. Perhaps this should be our preferred location at future meetings? The following is what I noted down about our discussions on the book. Additional comments from those that attended would probably be useful to fill in anything I have missed.

We started off talking about how you go from thinking ‘This design would be better if…’ to actually running through a series of specific refactorings. I find that when I see the need for large changes in an area of code, my instinct is just to rip it up and put it back together in the correct form. I then rely on the unit tests to ensure that everything is still working as expected. I don’t think others had quite the same experience – maybe they’re more disciplined than me? Steven made a point that if you’re using Java you are generally quite spoilt by refactoring support in the IDEs. If you are using another language, such as C++ then you are more likely to follow the refactoring steps as outlined in this book because you have to do everything manually.
We then discussed whether the book was showing its age by saying that “In our current understanding of software development” we design and then we code (page xvi). It was agreed that perhaps in much of the development community that is still the prevailing attitude.

Looking through the example which makes up the bulk of the first chapter, we talked about the “Replace Temp with Query” refactoring (page 21). I suggested that this was a refactoring that I would be unlikely to think of. In the example given, a total is requested from another object and held in a temporary variable. It is then used twice. After the refactoring the object is asked twice for the total, which causes the calculation to be done twice. So there could be a performance penalty, although in this case it was liable to be tiny. The reason given for doing this refactoring was that temps make it hard to split up long methods, so we should consider removing them. I suggested that it could also aid readability. We all agreed that this refactoring wouldn’t be the obvious one to do.

Moving on to the section about when to refactor, we talked about the paragraph where Martin Fowler suggests refactoring when you find a bug (page 58). I found his take on this interesting. He says that if you get a bug in a certain area of code, “it’s a sign you need refactoring, because the code was not clear enough for you to see there was a bug”. Steven said that there was a possibility that people would have exactly the opposite attitude: “I don’t want to touch this buggy code as it’s obviously unstable!”

Looking at Chapter 4, which deals with testing and JUnit in particular, we all agreed that at the time this material was needed. Nowadays though, most Java programmers should be aware of JUnit, as it has moved well into the mainstream.

Talking about the book as a whole, Graeme commented that coming from his perspective, (a background that doesn’t include Java or C++) the book seemed to be back to front. He found the initial example in Java to be difficult to follow, whereas the subsequent material about Why, When and How you should refactor was easier to digest.

From this point on, the discussion moved onto general talk about software development and I stopped taking any notes.