To refactor or not to refactor? (Part II)

So, when to refactor?
 
I am sorry if the first part of this article made you think that refactoring only brings problems. I still insist that the code should be readable and understandable. It also should be convenient to use and easy to maintain and develop. Positive approach is better than the negative one. So, think of refactoring not as of the source of problems, but as of your good friend who will come to rescue in an hour of need. Moreover, this friend can reduce the amount of such hours in your promising future. I would like to indicate several moments when refactoring is really relevant.
 

 
Nothing to do. Sometimes there happens project downtime when all critical tasks are closed and the new ones haven’t been set yet. It’s not really that there is nothing to do at all, but you have some free time. Spend it to improve the code. Give understandable names to substances, get rid of duplicates, re-write inaccurate architecture. Though no new features are added, you make contribution to peace of mind of developers who will continue working in the project. Believe me, this is very important.
 
Everyday pain. It happens that there is a part of the project that makes you sigh every day. And you hear similar sighs of your colleagues from the nearby working places. Of course, the release date is not tomorrow, but there are lots of important tasks. Nevertheless, week passes by week and it becomes more and more disappointing to see this code. Say: “This is enough!” If the business plan is created by your chief then you need to explain that this code just should be re-designed. If you have a customer, convince him that a week spent for refactoring will save much time in the future. If you work for users, make the decision that this time it would be better for the users to wait for a new version for one more week and then enjoy stable software and regular updates. Yes, it’s not that easy to agree with the others and with yourself, but do your best.
 
The problem of late refactoring. Don’t overemphasize the rule of early refactoring. Some developers think: “Now I will improve something and it won’t come useful – that’s a shame.” You need to understand that the application engine can contain critical parts that would better be written properly. Remember that the later you make refactoring the higher will be its cost because you will spend more time and effort for re-writing. Critical base code (that is used throughout the project) should constantly be in a good condition. It would be great for your team to have the following statement work: “Refactoring never comes late. It comes exclusively when it thinks it’s necessary.”
 
Meeting with a monster. You begin to add new features that should use the old project part which looks like a real monster: you’re scared only at a glance on the external interface. If you have enough time it would be better to fix code base and then focus on the new functions and don’t get distracted to add some kludges for code re-use.
 
Reasonable perfectionism. Have you noticed bad code? Want to fix it? Really want to fix it? If you really want it, do it. But pay attention to the word “reasonable”. Correlate time spent for refactoring to benefits you get from code improvement. Don’t postpone the deadline and don’t go deep into infinite improving of the code. Though if you refactor timely and reasonably, the project will succeed.
 
As a summary
 
All the above is a personal summary of experience related to the work on some projects. Of course, I haven’t covered all situations. Every team has its own requirements to the code, its own business plan and its rules. I am sure many developers have a couple of stories like: “And there was a case when all the advice doesn’t work”. This is absolutely ok, it should be like this. There is no silver bullet to define the amount of effort for code optimization (like “We will refactor every day for 47 minutes and 23 seconds and everything will be ok”). In your certain team, in every certain project and based on your personal experience, you need to find the golden mean between adding the new code and improving the old code. I agitate for reasonable approach to everything, without fanaticism (“Why improve the code, no new functions will appear” / “I need to make all code ideal, so it will be fine to work with.”). Be wise when allocating time for the work with the existing code and everything will be ok for you.
 
You’re welcome with ideas and thoughts on when it’s ok or not ok to refactor. One of the most valuable things in the field is experience of real developers who work with real projects.
 

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.