Change without changing: Keep your project healthy by refactoring your code
summary
Argues that two concrete techniques — top-down refactoring (Martin Fowler style: extract classes, structured destinations) and the flocking rules (Sandy Metz/Katrina Owen bottom-up steps) — let anyone safely change code without changing behavior, using tests at every step. Shows a worked example refactoring the first two verses of “12 Days” and a ski-lift ticket API, finds the flocking result clearer, and reports a team that devotes 10% time (every other Friday) sees faster feature delivery, far fewer incidents, and happier developers.
AI-written summary · about
chapters (13)
- 0:00Introduction to refactoring
- 1:08Technical debt and its impact
- 4:19Case study: Refactoring at Alex’s team
- 7:33About the speaker
- 8:14What is refactoring
- 9:17Top-down refactoring explained
- 12:31Bottom-up refactoring with flocking rules
- 21:45Comparing refactoring methods
- 26:20Why great programmers refactor
- 28:45Refactoring as continuous practice
- 30:10How to start refactoring today
- 31:38Recommended refactoring resources
- 34:28Q&A: Refactoring before or after features
