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?
I tend to see either ‘code smells’ like I’m repeating the same code over and over again or I see something that makes me think, ‘There has to be a better way to do this and I will go find it.’ It is part of how I write code and think it is somewhat of a good thing to have good code that may take a little longer to complete but that is much more easily scalable, maintainable, or have someone else take it and not have to spend days figuring out what I was doing in the code.
If you’re inheriting code, then I tend to think there are 2 schools of thought on what to do with it:
1) Keep your distance. This is where you make the required changes to get the feature in and don’t do anymore. If you know the module will be replaced soon or you only work on this once or twice a year, then I can see the logic in not wanting to spend lots of time fixing it.
2) Immerse yourself and fix it now. If what you doing is fairly extensive changes or is a piece of code that you’ll be working with regularly, then it may be viewed as part of the maintenance to do some refactoring or documentation or however you’d want to describe where bad code is turned into not so bad code as this will save you time later on.