My friend asked me about when is actually a good time for refactoring, or even what are the signs. According to several books i have read and my experiences in several projects, i’ll try to elaborate this thing.
Right time for refactoring is ASAP: refactor early, refactor often , i strongly believed in broken windows theory. BUT, don’t let this right thing sucks us really hard, so i think this is best-for-me practices:
Keep track of the things that need to be refactored. If you can’t refactor something immediately, make sure that it gets placed on the schedule. Make sure that people of the affected code know that it is scheduled to be refactored and how this might affect them. Remember that we’re code for people, not the opposite. And also, according to Martin Fowler ’s simple tips on how to refactor without doing more harm than good:
Don’t try to refactor and add functionality at the same time.
Maybe u will say: “Hey! ok i knew it, but what should i look first for refactor? i often stuck with no idea”.
Go back to your clean code definition. For my definition, i realize that any number of things may cause code to qualify for refactoring:
- Duplication. DRY is bad, really bad, trust me.
- Nonorthogonal design. You’ve discovered some code or design that could be made more orthogonal. In my experience, this step is the toughest one. If you are familiar with this, i believe that you’re such a good (maybe great!) programmer.
- Outdated knowledge. Things change, you know something better for your code, you know there are new better solution for your code. This is the time for you to keep up the code.
- Performance. Most common enforcement for programmer to look back to his code. You will be rarely concerned with this problem in aftertime if you’re a good programmer.
Maybe u will say: “Hey! i already knew it, even idiots know it”.
If so, i admit that you’re already a good software engineer. There’s nothing i can do for you, sorry for that. You’re really wasting time to read this. 
