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.