Refactoring is a process of editing software that doesn’t change what the software does, but instead improves it by making it more clear, more concise, or more direct. Refactoring is to code what structural editing is to prose. The debate about the utility of refactoring is just a rehash of the perpetual debate about revision. Everyone agrees that you ought to revise and that you never can revise enough. There are people like Mozart and Trollope who never revise and who do just fine, but most writers agree that’s fine for them and not a great idea for you and me.
Most of the classic refactorings run in two directions. We can Extract Method to break a long procedure into small and reusable components, and we can Inline Method to get rid of a small method that’s not pulling its weight. We can Pull Up Method to let a bunch of subclasses share common behavior, or we can Push Down Method so only the subclass that uses this behavior needs to know about it. Refactoring then becomes a matter of hill climbing, gradually improving the entire work by making a series of minor changes that facilitate larger and larger changes. When refactoring, how do we know which way is up?
Two broad approaches to the topography of code have been proposed. We move away from code smells, and we refactor toward patterns. These make sense, as far as they go. We should repair blunders in code just as we’d fix grammatical accidents or mixed metaphors, and if we see an opportunity to take some scattered code and rewrite it in a clean, ordered, and structured manner, that’s always a good idea. But these are exceptional cases. How do we refactor when there’s no grand pattern at hand and where we don’t see a straightforward way to expunging a code smell?
This is a central question of the craft of software today, and it’s seldom discussed. We talk around the question by contriving ever longer lists of code smells, but that’s not really a solution: code smells should be things we agree are usually or always bad, not things that might often be perfectly fine. We talk around the question by assuming that management won’t let us refactor even the obvious cases and so worrying about subtle situations is a waste. But not everyone has a pointy-haired boss. I’m surprised there’s so little literature on this question. I think at this point I’ve covered the books, but perhaps I’ve missed great stuff in the journal literature. Email me.
My two cents holds that, when the direction of refactoring is not immediately clear, we drive the ponies in the following directions:
else clauses. The gate is straight down.
If you’re new ’round here, I’m deep in the weeds on Tinderbox Six. Tinderbox is a tool for notes, a spreadsheet for ideas that helps people visualize, organize, and share complex interlinked ideas. It’s a knowledge representation system for everyone’s everyday knowledge work. If you’re interested in the design, you might enjoy my book on The Tinderbox Way. You can download a free demo of Tinderbox 5. There’s a terrific user community.