A Tale of Two Codepaths: Notes on a Refactor
summary
A yearlong rewrite replaces an inheritance-heavy payment plan system with a configuration-driven, composable design that uses the verbalize gem for single-purpose action classes, isolates routing with seams so one subtype migrates first, and preserves the public interface by overwriting associations to read new tables. Release uses feature flags via environment variables to ship dark, integration tests exercise idempotent actions and transactions, and the plan insists on documentation, staged migration, and scheduled deletion of deprecated code.
AI-written summary · about
chapters (37)
- 0:00Intro
- 0:42Where I work
- 2:37Why refactoring
- 4:07Planning and design
- 4:23What is refactoring
- 4:51Refactor at work
- 5:22Refactor
- 5:49Key Indicators
- 6:21Payment Plan Architecture
- 7:07Needs
- 7:29First Things First
- 8:00Document
- 8:17Design
- 9:20Guiding Principles
- 10:58Plan
- 11:51Verbalized Jim
- 12:19verbalize
- 13:11Getting there
- 13:21Planning
- 14:26Seams
- 14:59Case Study
- 16:16New Public Interface
- 17:47New Data Structures Example
- 19:36Why Release Change
- 21:35Inflight Population
- 22:25Example
- 24:00Integration Tests
- 24:17Idempotency
- 25:31In hindsight
- 26:02Things to remember
- 26:36Clean up after yourself
- 27:09Delete in hindsight
- 27:21Take care of yourself
- 27:35Avoid burnout
- 28:02Remember the basics
- 28:26Have fun
- 28:49Takeaways
related talks
41mOff the Tracks - Challenging the Rails Mindset
32mLegacy Code: Big Rewrite or Progressive Rejuvenation?
33mEastward Ho! A Clear Path Through Ruby With OO Jim Gay
37mBuilt to last: A domain-driven approach to beautiful systems
31mWhat Comes After MVC
27mBig Rewrite Strikes Again
51mCompleting the Rewrite from Hell: Five Years of Technical Debt and How We Escaped
32mHot Swapping Our Rails Front End In Secret - A Rebrand Story