Refactoring: When do you know it's time and when do you do it?

Question

When do you know it's time to refactor/review some piece of code ? And better yet, when do you do it?

Probably like others, I've found myself knowing that something needs a refactor/review but deadlines and management left no time for that. I'd also like to hear how you include code review in the general development process.

Lately I've found myself doing it before working on new features/code. For example, if I have to develop something new or change something in module X of an application, I do a code review on that module. I found it also helps me understand the module better so I can then make the changes more easily.

So when do you know it's time and when do you do it? And most of all how do you include it in the planning of a project?

Answer 1

Refactoring isn't something I set aside time to do separately. I'm constantly doing it as I develop new code, or when I'm maintaining old code. Work it in to your normal routine and always look for things you can improve in your code.

To respond to the specific case you added in your own answer to this question: I think your situation is a perfect example of when it's a good idea to refactor instead of a total rewrite. Make sure you write a good set of test cases for the code in question before you change a line of code. If the code fails some tests it will serve three purposes. First, it will give you specific areas to focus your efforts on. Second it will give you a solid justification (to your boss) for working on the code. Third is the standard unit test safety net that you want to have in place any time you refactor code.