Refactoring is important part of Agile methodology. As they say no code is ever complete and there is a good scope of improvement. As most of my work experience include traditional SDLC models, I always refrain myself from accepting changes and if it becomes mandatory that goes as Requirement bug or Design bug if not change in requirement.
That was horrible.
That was painful too.
Now with Agile practice, you would say – well, I am open for any changes because my design supports that and importantly my mind too! Does that sound interesting to you?
OK, then there are people (Uncle bob, Martin fowler, etc…) who are ready to solve your problems. Being late in the Agile game, it is glad to see that there are tested patterns and practices that you can follow to ensure success in your software projects.
One of such practice they follow is Refactoring – continuous code improvement. Though it is de-facto in Agile, there is no wrong to practice it in other software execution models.
Definition of Refactoring as per martin fowler’s dedicated site:
Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a 'refactoring') does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it's less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.
Click on below links to find well researched articles to dig more.