“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
// 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
2. Someone else will fix it
3. My time is better spent increasing functionality
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…