Since Fowler’s Refactoring book and adaption of the this term in the agile community, everyone is onboard for refactoring. It’s a great tool to prevent stale code. An ability to adapt to change is a survival
for any business and you continuously need to align your software to make sure it can change with speed of the business.
Strictly speaking, refactoring is modifying a code without changing external behavior. Often at the end of release cycles, developers apply quick hacks to finish the deliverables. Most agile environment dedicate a few days after each release to clean up the code. Many also use a geek week after a couple of iterations to do this refactoring or make structural changes to the application. The point of my rant is two fold refactoring: types of refactoring and when to use refactoring.
A software needs to continuously adapt and modify as business requirements change, however I find people use the term refactoring too loosely. I consider refactoring a minor change in the code without breaking the contract, however every day I hear people use the term “refactoring” when they mean redesign, rearchitect or completely rewrite the software or a piece of software. I acknowledge it’s very buzzword, but too often it’s used improperly. I have seen a number of projects that start from modest size with a couple of average developers to large size. In many cases the code is not properly maintained and incurs high technical debt. The development team may address the design or architecture issues that are at the heart of problem and start making major changes in the software.
Such effort of major redesign or rearchitecture cannot be labeled refactoring. Instead, they should be referred as design refactoring as opposed to code refactoring. Ideally, development staff need to allocate a few days or a week quarterly to address the design and architecture issues and adapt its
design with emerging needs of the customers. You can call it a geek week and spending a week quarterly will be a lot effective than rewriting the software.
Most teams favor speedy delivery of the software and often this gives the impression to move ahead with minimal changes for design, or architecture or refactoring. I find that architecture needs to be continuously evolve based on needs and small changes to design prevent code rot or technical debt. In some cases, it may increase the scope of the project, for example you may need to use a different database or service platform to support performance or scalability. For a sizeable project, it make sense to spend a few weeks to nail down immediate and emerging needs of the application so that it is able to support demands of the software. One thing that can make a big difference is having an experienced architect who has build similar systems before and understands the business domain of the application. Having a an architect helps that the software architecture is consistent and key design aspects are preserved when building new components or updating existing components.