DevOps 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

Refactor Code Often, Continuously, Every Iteration

03.27.2013
| 3884 views |
  • submit to reddit

Refactoring is a way to improve code quality over time using incremental set of improvements – the idea is to increase the ability to make changes safer and faster and is not meant to deliver new functionality per se. For systematic reuse to succeed, refactoring has to happen often and on a continuous basis.  Why? It provides several benefits from a systematic reuse perspective. For instance:

  1. You will learn which aspects of the code base have the most technical debt – what’s complicated to understand and extend/enhance? which parts of the codebase are difficult to verify via automated tests?
  2. See repetition more often and will eliminate redundant methods, classes, even entire chunks of functionality – over time, you will see the same capability being provided by a different library, or there is a new requirement in a project that can reuse the capability if changes were made to it etc. Finally – and this happens to me a lot – you ask yourself – “what was I thinking implementing it a certain way when there is a better approach?”
  3. Systematic reuse needs deep understanding of the domain – the team needs to tease apart different technical concerns, identify which ones are relevant for the business, and identify variations within the scope of candidate reusable components. Which brings us to the most important question – are the assumptions made earlier about the domain and the subsequent design still valid? This continuous validation and re-validation of the core underlying assumptions and design choices will ultimately decide the reuse effectiveness of the component
  4. Over time, doing this will provide the team with a valuable data on providing estimates – which parts of the codebase are tricky? which ones lack tests? which ones are bug infested? All these aspects weigh into an estimate and continuous refactoring will give the team very good insights.

So, please don’t wait for a project or a deliverable to arrive – start refactoring every day and across every project :)

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.)