“Refactor now, not later”

Farblondzshet in Code - Refactor now, not later

“Imagine this situation (one I’ve been in too many times): you have been working on a piece of code and have created a complicated/intricate function. You look over your work and realize it is an ugly mess; the function is over 100 lines long and a tangled jumble of logic. However, it works and is tested; you are tired of working on this function since you have already spent so much time on it. At this point you consider two options: refactor the code or leave a comment indicating that this code should be refactored.

// This code needs refactoring

// Refactor this later
void SomeoneRefactorMeSinceMyCreatorHatesMe()
{
// Save me
}

It is tempting to leave a comment to refactor and move on, but this decision is supported by some problematic assumptions.

1. I will fix it later

You won’t.

…

2. Someone else will fix it

They won’t.

…

3. My time is better spent increasing functionality

It isn’t.

…

Refactor Early, Refactor Often

Quality of code is vital to a healthy software project. It may be scary to tell your project manager you will not ship functionality because of refactoring needs, but a good manager will appreciate that doing so now is better in the long run, and relying on a future fix is detrimental to the project. While it may feel more productive to move away from one piece of laborious code, in the end take pride in clean and easily understood code. Your team will thank you. ” [GD: Leach level: 80%. Please click through and give Matthew link love]

You might think this is common sense. The problem is that common sense isn’t all the common (and it’s easy to ignore too). We’ve all been there done, that. I know I’ve said all three of the above items before and been sorry every time. Sometimes we need to take a deep breath and just do the right thing, right now…