Just me, Steven and David turned up for this one. We were looking again at Michael Feathers’ book Dealing Effectively with Legacy Code.

Steven began by saying that he still thought it was a good book, with a poor title. This was the general consensus last time we discussed it. I’ve certainly picked up some techniques from it, in particular the idea of subclassing the class under test to stub out external dependencies. Steven said that originally he’d thought that there might be some overlap with Martin Fowler’s Refactoring, but having thought about it he decided that there wasn’t. Everywhere where this might happen, Michael Feathers references Martin Fowler. I suggested that this book was probably one of the most under-appreciated books in the area of refactoring and design.

A technique which I found interesting this time was “Scratch refactoring” which is refactoring just to learn about the code. Steven agreed but was slightly concerned that there would be a temptation to keep the refactored code rather than throw it away. (Remember, you have no tests for this…)

Another interesting technique was “Characterization Testing”, which is creating tests simply to document what some code does currently. This can then be used to allow refactoring to take place. These tests can subsequently be thrown away and replaced by proper unit tests once the code is in better shape. I suppose the danger is once again that this scaffolding will not get discarded.

Steven mentioned that the chapter on testing code that is all API calls was particularly relevant. He has this exact situation and had always thought that this code was not testable. Having read the book he may get it under test.

David (arriving a little late) said that he thought it was a brilliant book. The only problem is that he would prefer a small number of files to look at whereas with Java you tend to get something of an explosion of classes. Using dependency injection tends to exacerbate this. We moved on to discussing dependencies between packages and I gave Structure 101 a name check. I’ve used this at work to keep dependencies in check – a fact which I have blogged about.

We moved on to the idea of “Architecture as a story” which Michael Feathers discusses in Chapter 17. The idea is that if you can encapsulate the architecture as a story it makes it more likely that it will survive over time. Something like having an oral tradition in place of a document.

Finally, Steven said that he thought that this book was one he would aim to keep close by in future. So when he needed to get code under test he would be able to refer to it for help.

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…