Panel Discussion Refactoring
summary
Concrete case studies about refactors and tooling not slogans: a Spree checkout/state-machine change takes four weeks, reworking adjustments takes two months, and an ActiveRecord overhaul spans three to four people and still breaks public APIs. Emphasis on tests first (or write them before touching legacy), practical tricks like global search (Sublime/Vim) and injecting runtime traces to find use sites, plus when refactoring causes API churn and how far teams actually go.
AI-written summary · about
chapters (17)
- 0:00Refactoring panel intro
- 1:55Panelists' intros
- 5:31Refactoring and test-driven development
- 7:01Dynamic vs static refactoring
- 8:25Ruby refactoring tools
- 10:34Refactoring priorities
- 11:59Refactoring expertise
- 14:47Long refactoring projects
- 16:51Refactoring in open source
- 18:59API compatibility in refactoring
- 21:44Team refactoring at scale
- 25:00Version control for refactoring
- 27:09Solo vs team refactoring
- 29:06Over-refactoring signs
- 34:53Q&A on API refactoring
- 41:54When to refactor
- 43:42Refactoring resources
related talks
50mRefactoring Is Not Just Clickbait
48mRefactoring from Good to Great - A Live-Coding Odyssey
01h 04mRefactoring Is Not Just Clickbait
35mQuickly and Safely Refactoring Legacy Code
31mLessons learned from refactors and rearchitectures
34mData-Driven Refactoring
07mOne Thousand and One Stories: a Large-scale Survey of Software Refactoring
12mImpactful Refactors: Refactoring for Readability