Definition and Core Principles of Refactoring

Key Insight

Refactoring, precisely defined, is either a noun—'a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior'—or a verb—'to restructure software by applying a series of refactorings without changing its observable behavior.' This means a two-hour refactoring session could involve dozens of individual, smaller refactorings, such as 'Extract Function' or 'Replace Conditional with Polymorphism.' Critically, refactoring specifically implies applying small, behavior-preserving steps, contrasting with general code cleanup or restructuring.

The essence of refactoring lies in its behavior-preserving nature, meaning the code should fundamentally do the same things as before, even if internal mechanisms like the call stack change. This allows developers to stop at any moment without the code being in a broken state, differentiating it from scenarios where code is non-functional for days during a cleanup. While refactoring alters internal interfaces, like 'Change Function Declaration' or 'Move Function', the overall user-observable functionality remains constant, and existing bugs should persist.

Refactoring differs from performance optimization primarily in its purpose. Refactoring aims to make code 'easier to understand and cheaper to modify,' potentially affecting speed positively or negatively. In contrast, performance optimization solely prioritizes speeding up a program, even if it results in code that is harder to work with. The 'Two Hats' metaphor suggests distinct activities: adding functionality involves adding tests and making them work, while refactoring focuses purely on restructuring code without adding new features or tests (unless a missed case is found or an interface changes).