October 17, 2009

...Learn TDD with Codemanship

So You Think You're "Refactoring"?

I've been sitting through dozens of videos of people purporting to be doing refactoring on the old Interporn this last couple of days. I'm very curious as to what the huddled masses think "refactoring" actually is.

Of course, I know what refactoring is, because I'm great. But it's very helpful to know what kind of things young and impressionable developers are being taught about this critical discipline.

The first thing I've discovered is that the majority of people who think they understand refactoring - some well enough to dare to teach it - actually don't.

Refactoring is a very strict, disciplined approach to restructuring code. When you watch someone doing real refactoring, it should look like a professional pool player carefully, thoughtfully, accurately working their way through all the balls on the table. Every shot has a clear goal. They can name exactly which balls should go into which pockets after each shot, and they have a plan for getting the cue ball where it needs to be for the next shot.

When I watch most people refactor, it looks more like someone just smashing the balls randomly around the table and hoping for the best. Indeed, that's how I play pool. Because I'm not very good at it. It's rare that I get two balls in a row.

Another analogy for refactoring is chess, in that both disciplines have well-defined moves. Sure, there are wider stategies you can learn, but these must be executed as a sequence of these primative moves. Larger strategic and wholesale refactorings - the stuff that can fundamentally change an architecture - must still be executed through a sequence of lower-level refactorings, like Extract Class, Move Method, Convert Local Variable To Field, and so on. And your code must still work correctly after each of these "moves", evidenced by running the tests.

So when someone tells me they are "refactoring" their code, my first question is "what is your goal?" They must be able to clearly articulate exactly what the end result should be. I would then ask them which refactoring they are going to do next. Are they going to extract that duplicate code into a shared method? Are they going to introduce a new object to wrap up those eight parameters? They should be able to explicitly name their next move. And finally I would ask them "when did you last run the tests?"

And those of you who think they already do refactoring, you may well say: "well, we don't necessarily have to be as strict about it as you".

Actually, yes you do. That's kind of the whole point.

Posted 13 hours, 45 minutes ago on October 17, 2009