Many people misunderstand refactoring. So, let Wikipedia explain it:
Code refactoring is any change to a computer program's code that improves its readability or simplifies its structure without changing its results. In agile methodologies, refactoring is an integral part of software development.
I heard a guy label refactoring as redesign. As “clean up” occurred (by me), he called it redesign – poisoning the project with foolish misnomers. Although “rewrite” might be closer, it shows a misunderstanding of refactoring and its purpose.
Refactoring is a responsibility.
Refactoring is essential to software development – end of debate. Code is not created equally. Just because code works does not mean code is not a candidate for refactoring. Just because timelines are lean does not mean refactoring should be skipped.
The refactoring beneficiary is the business owner, bringing maintainability, longevity, performance, and reduced errors to their software investment. In many ways, it is too expensive not to refactor.
As a developer, I desire function and delivery. I am measured on accomplishment and velocity. As an architect, I desire form and consistency. I am measured on performance and maintainability. These are in conflict. Developers are predisposed. Analysts are confused. The architect must be dedicated to his discrete responsibilities, typically swimming upstream near a project’s end.
Refactoring is not redesign.
Here are examples of redesign. Change in tiers, change in security, change in technologies, change in patterns, change in tools, change in transport, change in inheritance, and change in interfaces. In some cases even those can be “tweaked” without introducing a redesign.
Here are examples of refactoring. Reworking flow logic, reworking looping logic, relocating classes, adding members to base classes, renaming variables, extending a method’s signature, adding trace logic, increasing exception handling, changing label fonts, and resizing a form.
Refactoring is typically a result of personal or peer code review. Like proofing documents, edits (event significant ones) are sometimes necessary. The information may be present, but the usability and readability may be diminished by a simple first draft.
Solution Design should be worked out near the project’s start. As no one is perfect, tweaks may be necessary. As no one is clairvoyant, amendments may be necessary. Still, design precedes significant development – which is the implementation of the design.
Refactoring corrects, simplifies and synchronizes implementations. Errors are caught in testing, complexity comes from iterative requirements, and discontinuity occurs with multiple developers. None can be worked out until after development is considerably accomplished.
If you think refactoring is the same as redesign, think again.