Refactoring Pro-Tip: I use naming, isolation, and noise-filtering as strategies to keep the coder’s intention at my fingertips. (I’m actually jonesing to write some geeky material in this series, but I’ve got one more of these pesky abstract philosophy things before I can get there.) First, a silly line from a silly movie, Airplane, which makes for a good Friday night comedy if you want that. (Paraphrased from memory.) "There’s a problem in the cockpit." "The cockpit? What is it?" […]

Refactoring Pro-Tip: The triggering events for refactoring vary, but the reason we refactor at all is the same each time, regardless of occasion: we refactor to enable change. The most obvious and direct occasion for a refactoring is this: I want to add new functionality and preserve old functionality, and it will be easier to add if I first schmoosh the old functionality around a little to make a little hole where the new stuff will fit. When I do

Refactoring Pro-Tip: Terrible code is not a good excuse to be mean, because terrible code is not well-correlated with having been written by terrible people. Look, y’all, it’s me, here. I love a good rant as much as the next Old Testament prophet, surely you know this. But . . . but . . . When I work with a new team, a key element of what I do is figure out how to integrate my line of advice, which

Refactoring Pro-Tip: "Easiest Nearest Owwie First". When facing especially weak code, it’s easy to feel daunted; there just seems so much wrong with it. To get my mojo on, I find the simplest infelicity to fix, I fix it. Then I do it again. Everyone encounters code from time to time that she does not understand. This is true for the noob and equally so for the olb. It is a fact of being a geek. Early in one’s refactoring