Refactoring is a process of redesign that prevents software entropy, and was first coined as a software development term during the early days of the Smalltalk community. Refactoring, in itself, is nothing amazing and in most cases happens without many software teams consciously aware they are participating.
Unfortunately, this lack of awareness is exactly the reason why it doesn’t happen as often as it should in most projects.
David Thomas and Andrew Hunt (authors of The Pragmatic Programmer) explain that software design and development is more akin to gardening then to bridge construction. This metaphorical relationship is most easily seen in the way that software design can change rapidly over time. During the development phase many parts may become unusable (“compost”) while other parts may need relocation or pruning. As designers it becomes necessary in many situations to change the structure of many inter-related programs, which is natural. Refactoring, however, is the act of consistently looking for ways to simplify the existing code even in places that it is not necessary.
Refactoring, however, is the act of consistently looking for ways to simplify (improve, clean-up...) the existing code...
Many of the Agile movements have considered refactoring as one of the most important parts of the development phase. Reasons for refactoring vary, but the most important ones focus on replacing bad design patterns. These bad designs include – code duplication (areas that violate the DRY: Don’t Repeat Yourself principle), non-orthogonal design (portions of code that are too closely coupled with other modules that could be separated), performance (although processor speeds continue to increase, true enterprise level software should not be poorly written), and outdated implementation (solving problems based on an old implementation requirement, then having patches for those outdated modules).
Refactoring requires that you take a few precautions to prevent potentially corrupting the project or removing vital functionality. Martin Fowler suggest that you never try to add new functionality and refactor at the same time. Additionally one should never begin refactoring before a thorough suite of automated tests are in place (this helps prevent an introduction of previously seen bugs).
...never try to add new functionality and refactor at the same time.
By adhering to the idea that refactoring is necessary and a perpetual step, development teams may benefit from smaller maintenance requirements. As Hunt and Thomas state “Refactor Early, Refactor Often”.