Comments on: How to Refactor like a Something star

By: Ben Butler-Cole

Ben Butler-Cole — Wed, 30 Sep 2009 22:34:54 +0000

I would add: find a safe path. The ideal refactoring consists of a series of small steps that are known to be safe (that is, they don’t change the behaviour of the code). Sometimes you have an improved design in mind but it isn’t obvious how you get *there* from *here* (which reminds me of a joke about asking for directions). In that case it pays to try various routes to your destination (checking in frequently, being happy to revert) and persist in looking for a safe route.

As soon as you step off the path and make (even, what you think to be, temporarily) breaking changes then all is lost.

The great side-effect of this is that you can check in and walk away at almost any time, knowing that you have at least started things moving in the right direction, even if you haven’t finished what you set out to do.

Ben

By: Siim

Siim — Wed, 30 Sep 2009 10:32:15 +0000

to felix:
I think by top-down she meant that when refactoring class’s public interface, for example, you should first look its usages and start from there if necessary. And then proceed with class refactoring. When doing opposite, you could end up with big bubbling effect like Sarah described.

By: Jen Smith

Jen Smith — Wed, 30 Sep 2009 07:34:34 +0000

I can see the argument for dumping all low level unit tests when refactoring a subsystem (like your login example) – if the code is in that much need of a rewrite then the current unit tests aren’t going to help.

But in the case of smaller changes to fairly well-test-covered code, you can often leave the unit tests in place. Even if you need to put some ‘Assert.Fail()’ lines in a few tests here and there, the behaviour is still documented and you can revisit it later.

Parallelizing can work very well at the method level too. I have often started a refactoring by adding in the new method to be used and gradually moving callers over to it. That way you don’t break existing tests/behaviour until you actually need to and can perform regular checkins. Gives you a good scoping tool as well: i.e. ‘We will get rid of all calls to this guy then stop and do something useful’.

By: felix

felix — Mon, 28 Sep 2009 21:47:48 +0000

Interesting one. Even though I don’t quite understand, what you mean by top-down introduction of new concepts. I usually find that if you don’t go for the rewrite (possibly because there is no nice interface in your existing code base), it’s far easier to start extracting small concepts until the bigger ones emerge. But then again I think the rewrite (of a well defined subsystem) has had way too much bad press in agile circles.

By: Mark Needham

Mark Needham — Mon, 28 Sep 2009 14:18:23 +0000

Nice post – I particularly like the bits about doing refactoring in parallel to existing code – I’ve found that works out much better than breaking chunks of code while you try to change it.

Sometimes it’s also interesting just to take a copy of the code base on another checkout and just play around with refactorings while not caring whether or not you break anything.

That can be quite interesting for identifying abstractions that weren’t obvious previously or showing other ways the code can be improved.

By: Rob

Rob — Mon, 28 Sep 2009 11:23:55 +0000

Nice post Sarah!

I have to admit sometimes I am too quick to code when refactoring – and it has cost me. Recently I have been adding a process to my dev work (incl. refactoring) – I called it COMIK (http://bit.ly/4eMOm2) but the main emphasis is on good planning.

As you put it “painting yourself into a corner” can be both demoralising and frustrating (time wasting aside!).