Refactoring could be tempting, especially when you’ve finished reading a tech book, or some training course, you might feel yourself capable enough to get something done. After all, you can’t tolerate the shitty codes in the old big rotten code base anymore.
The rush won’t stop until you finally strike into something. You might underestimate the complexity of code, the difficulty of refactoring, or even worse, the time you may spend. These may result into a half-way refactoring. Or after crawling across enormous slumps, you are lucky enough finishing your job, either missing your expectations and successfully making another garbage, or having insufficient improvements, making your effort pretty useless.
It’s time to sit down before we spend more useless effort. See, refactoring could be —— and is usually, overwhelming, and that’s the fact if you are a coding rookie like me.
But maybe we can do it in a smart and easy way.
The Boy Scout Rule
leave your campsite better than you found it. In the programming context, leave the code segment than you found it better before you commit it. I’d like to call it micro-refactoring.
you don’t have to touch everything when it comes to refactoring. writing nicer code, doing simple things with daily commit might accumulate into appreciable result.
Weighing Benefits
there is a saying that a double or triple improvement is not enough for users from your competitive users to switch to your product. A promising number would be 10 times. Same when it comes to refactoring. If the benefit is not promising enough, you might need to think cautiously.
Refrain From the Urge
Consider refactoring as last resort. You have tons of things to finish, and refactoring is just one of them.