Mindless Refactoring

I teach a unit test class. In this class I try show the gamut from techniques you can apply to "traditional situations" all the way to TDD/Extreme Programming(XP), with a strong emphasis on the XP end of things.

This past monday, the class topic was on refactoring. I covered the following topics:
- what it is
- why you want to do it
- smells
- refactorings
as well as a demo where I refactor live in front of the class.

(begin sidebar)
I typically employ the live demo while teaching so the students can get a feel of what it should look like and/or how it might look when they get the hang of it. This practice is esp. needed when trying to convey skills that are non trivial to develop.

How many times have you heard, "that doesn't/won't work," which often really means someone hasn't bothered to put the effort to make it work. If I said a jump shot doesn't work, because after my 3 attempts to make one failed, you'd laugh at me. But similar low effort attempts followed by immediate dismissal are common. Ironically, you can show some people right in front of them that "it does work" and they'll still dismiss it.
(end sidebar)

Most of the students are from the same company, so they all have a similar background: a company that isn't Agile that's trying to go Agile. Read this as not much in the way of unit tests, automated or not.

As I was blasting through the refactoring, a student pointed out how due to my safety net of unit tests, the refactoring was "mindless" in that I didn't have to think at all in order to verify that I was going in the right direction. I merely hit the Run button and I knew instantaneously whether I succeeded or not. They were impressed with speed and smootheness of my refactoring cycle:
- apply refactoring step
- check
- fix/undo if broke
- continue

The tiny yet regular steps, uninterrupted by debugging time is something that many have not seen. The safety net of unit tests, along with the small steps that manage the complexity of introducing a new defect is just not how most people are doing things. The live demo gave that one student the revelation of how refactoring can indeed be very doable when it's as "mindless" as it was for me. The state of the code/coding practices at his job just didn't yet provide the facillity for making refactorings mindless.

This reiterated to me how much of TDD/XP is about complexity management. In making the verify part of refactoring "mindless", I was able to concentrate on the real task at hand. This complexity management pattern permeates throughout TDD/XP at all levels.