Monday, August 29, 2011

Poop: The Refactoring Method

I developed an quirky technique for dealing with the intermediate states of a refactoring. I call it the "poop" method (no biological metaphor implied). This method is far less controversial than one might suspect, but it is mildly unsettling.

I find myself working in a legacy code base. Refactoring requires me to take several small steps, each of which leaves a sub-optimal intermediate state. I decide to mark the code with some kind of comment that will indicate that the work there is incomplete.

It needs to be a word that doesn't normally appear in code, and which is clearly and obviously undesirable. If I put TODO, it will either get lost in the other TODOs left by well-intentioned people, or else will be stopped by a lint tool that takes such things seriously. Most obscenities would also be a little too likely to be duplicated by someone having a bad day.

My marker comment should not be something so obscene that it will offend or embarrass myself or my reviewers. Something common in baby-talk and yet biologically insensitive will work. I add a comment that says merely "poop." The fact of the comment being in my code creates a mild sense of uneasiness. After all, I don't want my colleagues finding it in production code.

As I finish my refactoring, I do a global search. Sure enough, the word only appears where I've written it in as a marker. As long as I clean up the code and remove the markers, nobody will find a "poop" in my code.

Actually, once my friend George and I left a "poop" in our code. Our coworkers found it. It was easy to tell we'd been caught because the pair looking at the code were laughing and asking why it would say that. It was a little reminder that all was not complete and tidy in our little world. We immediately fixed the code and removed the comment.

I have also used this as an indicator that I need to rename a method. 

If I don't know what to call a method or test initially, the word 'poop' reminds me that I need to revisit that code and determine why it is hard to name. 

Usually poor naming is a sign of poor design; well-designed components seem to practically name themselves.

Maybe you object to the word, but that's okay. The value of the poop method is ensuring you will be uneasy in the presence of unfinished work. Come up with your own variation (be nice) and see how it changes your work habits.

Note: in 2015, Arlo Belshee covered some similar ideas in his article about the process of naming, specifically in moving from missing to nonsense

No comments:

Post a Comment