Our Fight Against Super Bad Patterns in Legacy Rails Apps
summary
Migrated three apps from Rails 2.3.5/Ruby 1.8.7 to Rails 4.2.1/Ruby 2.1 over about 11 months across three companies, kept production while refactoring and adding features. Replaced gems (file upload, pagination), moved assets to the asset pipeline, swapped Prototype to jQuery, removed attr_accessible for strong parameters, and wrote RSpec/Capybara specs after migration. Found and fixed four concrete anti‑patterns: too many layers (merged one‑to‑one models into rich ActiveRecord), dreamy methods (split and name methods), global hashes converted to value objects, and controllers split to avoid mass‑housing.
AI-written summary · about
chapters (10)
- 0:00Start
- 5:35Ruby & Rails Migration (Upgrading)
- 8:01Our Applications Kind of health check service B to B Handed over to our company from the other development company which originally developed the system
- 20:54We love good patterns
- 21:59Too many layers
- 24:40Deamy method
- 31:32This is the combination of 2 bad patterns
- 31:51You need to chase the identifier not to harm other features
- 32:14Dreamy method Write a different method for a different need Doubt adding an argument and "if" Extract common parts Use polymorphism Stop this pattern in early stage
- 32:46Conclusion
related talks
23mCrafting Rails Culture
36mWorking Compassionately with Legacy Code
39mThe Long Ball - Upgrading long lived Rails apps from 1.x-4.0
22mRiding Rails for decades
01h 05mLegacy Rails Q&A
41mExploring the History of a 12-year-old Rails Application
39mDown The Rabbit Hole: An Adventure in Legacy Code
41mOff the Tracks - Challenging the Rails Mindset
