I love refactoring, perhaps even more than writing new code.
For those of you aren’t software geeks, refactoring is the process of changing the structure of a body of code without changing the behavior. It’s about redesigning code so that does the same thing as before but in a different way. Usually you do this because you’re going to add new behavior to it, but the current design doesn’t allow you to. There are other reasons, but that’s the big one.
I just spent an hour working from home on a weekend, which I never do, because of something I realized late yesterday afternoon.
The project I’m on at work has a lot of what one of my co-workers described as “hand-crafted code.” The code does exactly what the first release of the product needed to it to do, and nothing more. In one way, that’s a good thing, because it wasn’t overbuilt. In another, it’s not, because the code is fragile and hard to re-use. Even worse, much of the code uses the Big Ball of Mud design pattern. There are lots of long methods, objects with multiple responsibilities, and modules that are hodgepodges of different pieces of functionality.
What I realized yesterday afternoon was how to eliminate two unnecessary and confusing functions from a module’s interface. This particular bit of code has been vexing me for quite a while, so I take any chance I can to clean it up. And as I moved the code around today, it really sunk in how much I love this kind of work. I love seeing the potential in a body of code, working within the current constraints, improving what is there. There’s something about the process of refining, of letting the new design emerge, that hooks into the synergistic part of my brain. A lot of my role on my current team involves taking functionality that other people have developed and making it work in ways or in situations they didn’t originally design it for. Other people can blaze the trails. I’m happy building the railroad behind them.
UpdateFitness: Ran 2.25 miles
Writing: 448 words, 258 average