|Industrial XP Refactoring|
RefactoringImproving the design of existing code
The following text comes from Joshua Kerievsky's book, Refactoring to Patterns.
What Is Refactoring?
A refactoring is a “behavior-preserving transformation,” or, as Martin Fowler defines it, “a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.” [F, page 53].
When we refactor, we relentlessly poke and prod our code to improve its design. Such improvements may involve something as small as changing a variable name or as large as unifying two hierarchies. Refactoring involves the removal of duplication, the simplification of complex logic and the clarification of unclear code.
To refactor safely, you must either manually test that your changes didn't break anything or you must run automated tests. You will have more courage to refactor and be more willing to try experimental designs if you can quickly run automated tests to confirm that your code still works.
We refactor in small steps to prevent ourselves from introducing defects. Most refactorings take seconds or minutes to perform. Some large refactorings can require a sustained effort for days, weeks or months until a transformation has been completed. Even large refactorings are implemented in smell steps.It's best to refactor continuously, rather than in phases. When you see code that needs improvement, improve it. On the other hand, if your manager needs you to finish a feature before they demo the software at an impromptu morning meeting, finish the feature and refactor it later. Business is well served by continuous refactoring, yet the practice of refactoring must co-exist harmoniously with business priorities.
Further ReadingRefactoring: Improving the Design of Existing Code by Martin Fowler.
Refactoring to Patterns by Joshua Kerievsky