The perfect, exact science of refactoring



Do you know how sometimes your code has this thing written somewhere, then you need about the same sort of thing somewhere else, then in another place, and you think "huh, guess I'll turn it into a function"? Do you know what's wrong with doing that? It doesn't have a cool enough name.

A normal person would call it re-jiggering. Don't laugh - it's in the dictionary: "to organize differently". It's the kind of word you use when you're improvising, or trying something new, which seems about right for writing a program. "Cleaning up" is also a good phrase. Sometimes writing a program feels like you're leaving a mess as you go, making progress slower and slower. You occasionally need to stop doing real work and clean up the mess.

Here's how it works: you write simple code to make a button. Later, you find out the colors need to be settable per each, which forces you to go back and do a rewrite. Next you're assigned to write drop-downs. The specs don't say they change color, but you won't be fooled again, and add that ability. Except, it turns out, drop-downs never need to change color. It seems like everything you do is wrong and time-wasting.

It's not about making mistakes. This sort of re-jiggering is the inevitable result of the program changing, and the program always changes, in ways you never would have guessed. The client changes their mind, testing reveals a problem with the specs, new hardware, you're working through a features list and aren't sure what you'll get to. It gets worse - you may know buttons will need color changing, add it, but something else forces a total button rewrite, requiring us to rip out this now-obsolete color-change code.

But suppose you're the sort of person who thinks programming is a more perfect version of reality. The sort of person who secretly believes the true purpose of programs is to have an inner beauty. It's inconceivable to judge a program by whether it merely does what it's supposed to. You need a word that implies that all of these rewrites are part of an orderly process - a reverent act that contributes to the final perfection of the code. That word is refactoring.

Refactoring is great since it sounds like prime factorization. That's the one correct way of breaking a number into parts. We want that certainty for our programs. We can't have it, but the word helps us pretend that cleaning up our code is an orderly process, following clear rules.

Some details about what this rejiggering is, and why it's tricky: if several places declare the same group of variables together, using them the same way, we should throw them into a class. To save time, do that if we suspect there will be re-use. When we're wrong, we just wasted time and made the program harder to read. Or it turns out they were using it the same way, but that changes -- now we're making a single overly complex "does everything" class instead of several simple ones. If a class will become complex, it should have private variables. We should do that in advance if we suspect. But again, when we're wrong, we've got another harder-to-use class. Some functions have lots of inputs for flexibility, but it turns out the inputs are always the same and all we did was make it needlessly complex. The opposite happens -- we preset the values and it turns out we need to change them later. Sometimes we like to hand-check events for more control, other times we like them automatic. It's better to pick one way and stick with it, except our program can change to prefer the other way,

I've talked to professional artists about something that seems similar to how program writing works. A painting starts with exciting ideas, sometimes high-concept, like smears of paint for inspiration. Then there comes a time when you hate it and want to start over the right way. But you have a deadline and are a pro, and work through your revulsion. Every finished painting is much worse than you hoped it would be, but other people don't notice, and that's the for-real artistic process at work.

I think programmers need to learn the same thing. That thing of beauty in your mind is great to get started, and can guide you as you write code, but you should never expect to actually make it. You're not factoring - you're using guesswork that time spent re-orging now will save more time later. And that's nothing to be ashamed of.



Comments. or email