Monday, 26 November 2007

Knowing When to Refactor

You're in the middle of implementing some new functionality when you stumble across some poorly written code. Fixing it properly will take some time and, for the stuff you're working on, you can get away with making a couple of tweaks. What should you do? Refactor it now? Or leave it for another time? If so, when?

Douglas Squirrel told me about a neat solution that I hadn't heard of before. The idea is that the first time you come across some smelly code you write a comment that says FIXME. Each time you encounter the code again, or someone else does, an extra X is added so it becomes FIXXME, FIXXXME etc. By the time the comment screams FIXXXXXXXME, you know what you have to do!

4 comments:

JP said...

that sounds cool ! we're gonna give it a try...

Steve Freeman said...

An interesting take. I've always used "Strike one", "Strike Two", etc. even though I don't play baseball.

David Chelimsky said...

Another trick I learned from Josh Graham is to identify FIXMEs and TODOs with dates and names e.g. "TODO (David 2012-12-04)". That makes it easy to assess how long something's been waiting around (and maybe remove it from the queue when it becomes apparent that it's not really important enough to fix).

PikachuEXE said...

@David Chelimsky
Oh that's great :)

I do use TODO but most of the time they are ignored :S

Even I am using RubyMine (Can view all TODO's)