Refactoring starts with the first step

Don't even start the mountainous refactoring task yet. Instead, start on something small you know you can do.

Let’s say you agree with my earlier message that refactoring in small steps is a good idea. But maybe you’re not sure how. You have a mountain of a refactoring task sitting before you. Where do you start?

I have a simple tip for you.

Start small.

“Bleh. Yeah, that’s the problem. How do I do that?”

Okay. Let me be more specific.

Don’t even try to start on the mountainous refactoring task yet. Instead, start on something small you know you can do.

Let me illustrate how I tackled my recently mentioned refactoring task. I knew the code I was working with had error handling problems. I wasn’t exactly sure what the solution was, other than the fact that it needed some refactoring. I didn’t even know what I wanted the end-state to look like. I just knew it was ugly. It had a smell.

Of course I came to this conclusion by reading through the code. But a smell isn’t enough to refactor yet. I need something more concrete.

So as I was reading through the code, I started to notice some problems. A few variables had confusing names. Or there were extra layers of unnecessary nesting.

So I would fix these things.

These are the sorts of things Kent Beck calls “Tidyings”. (Highly recommended: his new book, Tidy First)

“That’s a waste of time… fix the real problem!”

I don’t know if that’s your thought, but I’ve certainly worked with people who felt this way.

But it’s not a waste of time. There are (at least) two valuable things that happen when you begin a refactoring (or even a new feature) by cleaning up the surrounding code:

  1. The code becomes easier to read and understand the next time you, or someone else, has to work on it.
  2. You build up a more complete understanding of what the code does. That smell begins to become more concrete.

Eventually, after tidying up the code around the refactoring I want to do, a new design will tend to present itself. Then I can begin working on the “proper” refactor, with a new sense of confidence, and a clearer idea of both where you’re going, and how to get there in small steps.

As J.B. Rainsberger once told me:

You have some basic idea of, I want to remove duplication, I want to improve names. I feel comfortable that I know how to maybe move code from place to another, but I don’t know what the key abstraction that’s missing is. I don’t have a really big idea about where I want the design to go. I just know that this design makes that change difficult, and I want to move in that direction.

Then you sit down to do it and you think about, okay, roll up your sleeves, start doing a couple of small refactorings, extract a method, move a method from this class to that class, maybe rename something. You start to feel like I’m not really sure that this is actually getting any better, but now I have a clearer picture in my mind of what I wish it looked like.

Share this