Refactoring (Martin Fowler, 2nd edition)
Main Argument
The design of existing code can be improved continuously through small, behavior-preserving transformations. Good internal structure is what keeps software cheap to change; refactoring is the disciplined, everyday practice that maintains that structure as understanding grows, rather than letting design decay one shortcut at a time.
Key Takeaways
- Refactoring changes the internal structure of software to make it easier to understand and cheaper to modify, without changing its observable behavior.
- Wear two hats: separate adding functionality from refactoring, and never do both in the same step.
- Self-testing code is the safety net. Refactor in small steps and run the tests after each, so a mistake is caught immediately and localized.
- Code smells are heuristics for when to refactor, not rules for what to do: duplicated code, long function, large class, feature envy, divergent change, shotgun surgery, data clumps, primitive obsession, and others.
- When to refactor is opportunistic, not scheduled: the Rule of Three; preparatory refactoring ("make the change easy, then make the easy change"); comprehension refactoring; litter-pickup. It is woven into daily work, not run as a separate project.
- The economics: internal quality buys speed (the design stamina hypothesis). Neglecting it accrues technical debt whose interest is paid as ever-slower change.
- Performance: prefer clear code first, then optimize the few measured hotspots; clarity makes the later optimization easier and better targeted.