This time Miquel, Tom, Steven, Mick, Steve and myself met up at the Lamb and Flag to discuss Michael Feathers’ Working Effectively with Legacy Code.

We started off talking about the title of the book. The book is in large part about getting poorly structured code under test. Steven thought it was misleading, while Miquel thought that “Refactoring for Testing” would have been a better name. Mick suggested that it was a brave move, because it might have sold better with some agile buzzwords like “Refactoring” in its name. Instead Michael Feathers chose a name that some people could misinterpret to think it was about COBOL and PL/1.

Steven liked the book and likened it to Martin Fowler’s “Refactoring”. But like Miquel he thought that this was the book to have by your side to get the code in some sort of shape, while Fowler’s book is useful once you’ve got it under control.

There was then a discussion about the idea of making private methods public or protected to facilitate testing. It was generally agreed that if this was needed to get testing in place then it was a reasonable trade-off. Miquel pointed out that you have private methods to avoid mistakes, but that having tests in place is an even better safety net, so trading one for the other is worthwhile.

In a similar vein, we talked about the technique of extending a class in order to test it. This allows you to override parts of the class that require external dependencies. We liked this idea, and Miquel said he had used it on a real project (as I have done since). We agreed that this book has lots of good ideas like this in it, but it is hard to have a discussion in the pub about them. Steven said it was a good book to have around and Mick revealed the startling fact that it is more useful when actually on your desk, rather than on a bookshelf!

Mick read the book some time ago and never understood the diagram on p170 (Figure 11.13). He even spoke to Michael Feathers about it at the ACCU conference. Now he has come to look at it again, he still doesn’t understand it, but unfortunately he isn’t getting any response to his emails. So if you’re reading this Michael, Mick loves the book, but can you please explain the diagrams on p170!?

We moved on to “Programming by Difference” which is mentioned in the book. I didn’t think it was explained quite what it was. Is it simply the practice of putting new code into subclasses of existing ones? Steven pointed out that it is called programming by difference because the new subclass contains the difference between the old code and the new. Tom mentioned that this technique is also described in Refactoring to Patterns.

We finished off by talking about “feature sketches”. These show the dependencies within a class, unlike most of these sorts of diagrams that show dependencies between classes or between packages. Everyone thought that these diagrams should be generated by a tool and in fact Mick said that he had created a tool using DOT that generates diagrams from bytecode. We wait with baited breath for this to be released as an open soure tool…