In a discussion on the Agile Alliance Linked In Group, Michael Moles asked how refactoring fit into the agile process.
The Question
Refactoring: How does it fit into your Agile process?
We are in the midst of writing a new product, at this point the developers are realizing that some of the code should be refactored to improve performance and or clarity for ease of use. How do you fit refactoring into you Agile process? We have created separate backlog items for refactoring specific pieces of code. These backlog items are treated exactly like any other backlog item (meaning they have effort assigned and are committed to sprints by the team). What do you do when refactoring is necessary?
- Mike
General Consensus
Most folks (myself included) didn't really answer Mike's question. He wants to know how you schedule refactoring when it becomes necessary. But the general consensus seems to be that refactoring is necessary and should not be scheduled. Instead, it should happen as needed.
My Answer
In my mind, there are two types of refactoring; real-time and planned. In each case, we are changing the implementation without altering behavior. In each case, we need comprehensive test coverage. Without tests, we don't know for certain if we've altered behavior or not.
Real-time refactoring is a great behavior to cultivate. It is a natural part of the TDD flow. Red => Green => Refactor. We are continually looking for small ways to improve the code; rename a variable, extract methods to create a composite method, generally make the code readable, DRY, and well composed.
Planned refactorings tend to be larger chunks. We've realized the need create a base class and derive from it rather than have this complex conditional. We see now that we have a lot of responsibility in the wrong place and need to re-work a section of the code to reduce coupling.
Following TDD practices, we tend to have more real-time refactoring and less planned. This is good. It means the code is generally better composed. We are keeping it clean as we go along rather than letting it get bad and then asking for permission to clean it up.
Many agile teams adopt the practices of TDD and ATDD to ensure they can deliver working software and respond to change. For those teams, refactoring is a given.