Refactoring Is Not Just Clickbait
summary
Argues that refactoring is a design process not a menu shortcut: automated extract method and rename are common and useful, but many teams neglect extract class and data-representation changes that actually simplify behavior. Demonstrates with JavaScript stack representation changes (behavior-preserving but with different performance), the Gilded Rose control-flow → table-driven refactor that consolidates state changes, and a Roman-numeral example where repracing control flow with a data table or regex radically shrinks code. Tools speed work; social, API and testing boundaries decide whether refactors succeed.
AI-written summary · about
chapters (24)
- 0:00Introduction
- 2:33We love complexity
- 3:32Technical debt
- 5:13Technical neglect
- 7:42Architecture has inhabited sculpture
- 9:13Wheres refactoring fit in
- 12:50The history of refactoring
- 14:38Behavior preserving
- 18:16Right hand rule
- 23:31Definition of refactor
- 25:49Refactoring tools
- 29:15Rename
- 33:33Responsibility
- 36:09Decremental Development
- 37:39Decimal
- 39:26Carter
- 42:10Refactoring
- 46:06Data Structure
- 46:42Fred Brooks
- 47:21John Von Neumann
- 48:12Conventional Programming Languages
- 49:28Refactoring Code
- 54:47Big Systems
- 59:05Radical Change
related talks
50mRefactoring Is Not Just Clickbait
01h 04mRefactoring Is Not Just Clickbait
01h 07mRefactoring Is Not Just Clickbait
57mUnlocking The Awesome Power of Refactoring
55mHow To Approach Refactoring
18mImpactful Refactors: Refactoring for Readability
01h 00mHow to Approach Refactoring
45mPanel Discussion Refactoring