Agile Zone is brought to you in partnership with:

Vijay Narayanan is a systematic reuse evangelist building reusable data services and business process automation components. He has worked on several software projects ranging from single user systems to large, distributed, multi-user platforms with several services. He is a technologist focusing on software reuse, agile development, and Service Oriented Architecture (SOA). Vijay is a DZone MVB and is not an employee of DZone and has posted 43 posts at DZone. You can read more from them at their website. View Full User Profile

Why do we fear Continuous Refactoring?

  • submit to reddit

There are so many reasons why continuously refactoring code is a good idea – in fact, it is a sound investment for the overall health of your codebase. So, what could be some reasons why we fear doing refactorings? what could be the impediments to making changes?

In my experience, the #1 reason why developers fear refactoring is the lack of automated regression tests . This is why Martin Fowler emphasizes the need for tests prior to pursuing refactorings in his seminal book Refactoring. Without a comprehensive suite of tests, developers cannot be confident that changes to the code didn’t break existing functionality and it didn’t introduce new defects.

There are other reasons as well for fearing refactoring:

  • Not enough time during development – this is such an often repeated reason for a variety of issues :-) Here is the rub though: we learn most about the domain and the limitations of existing code with experience. This tends to happen at the “end” of an iteration or release cycle. Naturally, we don’t want to jeopardize our release to do refactorings. This is precisely why agile advocates the notion of continuous refactoring iteration after iteration. Your code reflects the state of the software (and the associated knowledge of the domain) at a snapshot in time. It is a work-in-progress – remaining that way till the product ceases to exist or be maintained.
  • Lack of disciplined effort to translate new domain knowledge into existing code. As a project proceeds, developers learn more about the domain and the gaps in their knowledge with respect to the domain. These gaps typically manifest themselves in various forms: needless abstractions, insufficient flexibility with known variations in the domain, and lack of domain-relevant concepts being modeled as first-class citizens.
  • Insufficient knowledge on using refactoring tools (e.g. using an IDE such as Eclipse, there are a plethora of refactorings can be implemented rapidly).
  • Lack of knowledge about refactoring tactics – moving methods, creating interfaces, replacing if..then logic etc. – that are necessary to keep a tidy, effective codebase
  • Unwillingness to improve the codebase on a continuous basis :-)
Published at DZone with permission of Vijay Narayanan, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Peter Luong replied on Mon, 2013/06/17 - 8:51pm

I think that if you have a comprehensive suite of tests, then a developer should not have any fear when refactoring. If you are trying to improve the current codebase at least you have existing tests that will determine whether or not you have changed the existing functionality.

If you come across a piece of code that you think could benefit from a refactor but you don't want to jeopardize the release then note it down and come back to it in the next iteration. It better to work on it at the beginning of the next iteration as opposed to the end as you are not exposed to the pressures of completing the task to meet the deadlines of the release window.

I don't think insufficient knowledge on using refactoring tools is a good excuse for fearing refactoring. There is enough resources out there like IDE cheat sheets to assist you in your refactoring. 

I think we should always be willing to improve the codebase. It may be beneficial for other developers if it improves the readability of the code, or to the business if it provides performance gains.

Suresh Murthy replied on Tue, 2013/06/18 - 12:25am

Hi Vijay,

Nice post. Have been in such a situation many times, when we are almost at the fag end of a sprint and we want to refactor stuff. But I believe introducing big bang changes without tests is inviting trouble, to say the least :) 

There is one particular aspect, i have always wondered. When it comes to refactoring controller code (assuming we are using SpringMVC) what I have seen is people rarely write Controller tests. Most of the testing happens with UI. Hence is there anything specific you have done, to take of this. It would help if you could share your experience.

Also, any best practices we can adopt while maintaining tests written for service/dao layer with junit4.x + spring.

Raja Nagendra replied on Thu, 2013/10/31 - 2:04am

Most of the fears are due to established Process thinking and Legacy Management thinking.. 

We at TejaSoft see Refactoring as the way to accommodate new with no friction.. This way we observed that, we save 70% of developer debugging time and 30% of Testing Time.

As we have been doing Code Audits of more than 20 million lines of java code, we now propose to conventional management on having separate refactoring team, whose focus and expertise is to enable smooth fixing of new feature and new bug observed..  so that existing team has a no way to put blame on legacy code. Our experience is that, with this approach, after few months, client developers himself get used to this style and do it as part of bug and feature addition and stop blaming legacy..This approach has helped at least in revival of two of the Products whose code size was of 1 million lines plus...

If systems want to sell fabricated complexity.. stick to Infy Process...and still produce tonn's of bugs.. which can be billed :) the cost of Intellect death in IT..and Your clients ill business fate...

Raja Nagendra Kumar,
- Experts in saving Millions $  in Engineering - through Code Quality Focus

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.