Accepting change and responding to change is a true Agile spirit in my opinion. During product development projects; user requirements change, UI changes, client expectations change, system behavior changes and to accommodate these changes your codebase consistently has to evolve.
Continues code refactoring is reality in Agile teams, a great piece of code in this sprint might be refactored in next sprint.
How Agile team deals with refactoring depends upon the
- Maturity of software engineering practices
- Desire to learn new things
- Exploring areas of improvement,
- Tolerance in product management team about consequences of patchy solutions
- Culture of doing the right thing for the client
On daily basis developers spot code smells and identify areas of improvement, small changes get implemented quickly and bigger changes get discussed, sometimes compromise solution is chosen otherwise features delivery or project due date gets the hit. Among these developments the communicating what has changed usually slips through the cracks because everyone is so focus on feature delivery.
Recently I ran number to workshops to identify challenges we face in continues refactoring and how to approach refactoring in a structured and systematic manner. We came up with a refactoring model that any product development team can follow make code refactoring more effective and easy to understand.
Refactoring Model Details
- Identify areas of improvements
- Define your goal
- Collaborate ideas
- Propose solution
- Time-boxed implementation
- Improve quality and/or performance
- Radiate knowledge
- Record achievement