Beyond The Rails Way
•
10 likes•3,535 views
The Rails Way is the reason of Rails success. It's also the reason of Rails disappointment. Why is it so? Is there any alternative?
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Beyond The Rails Way
Similar to Beyond The Rails Way (20)
More from Andrzej Krzywda
More from Andrzej Krzywda (18)
Recently uploaded
Recently uploaded (20)
Beyond The Rails Way
- 1. Beyond The Rails Way Andrzej Krzywda http://rails-refactoring.com
- 2. Why is Rails business-friendly? • Quick to produce a prototype • Prototypes are production-ready enough • Easy to add new features • Possible to turn a prototype into proper production app
- 3. Because of The Rails Way
- 4. Why is Rails not business-friendly? • Because of The Rails Way • Business loves the speed of adding new features • … but loves predictability even more • There’s no predictability with The Rails Way
- 5. The Rails Way • Scaffold-like code in controllers/views • ActiveRecord goes all the way up to the view • features implemented with external gems • external gems assume ActiveRecord in the views • all models connected to each other with associations • non-trivial things implemented with callbacks, filters, state-machine, STI, validations • some JS/Coffee on top of the server-rendered html • one monolith app • Convention over Configuration • Magic (relying on meta) • Don’t Repeat Yourself • “We’re 95% done with this app, can you help us finish it?”
- 6. When is The Rails Way good? • for business/coding people to prototype • for less-experienced developers • to quickly get a result • for geniuses • they will handle any code • mostly-CRUD • logic-less apps
- 7. When is The Rails Way bad? • advanced developers • complex business logic • long-living business processes (like order) • multiple teams • predictable speed of work
- 8. If not The Rails Way then what?
- 9. Beyond The Rails Way
- 10. The Next Way
- 11. The Next Way • service objects • repositories • form objects • adapters • domain objects • events
- 12. The Next Way is heavily influenced by DDD and classical OOP patterns
- 13. It’s not all or nothing
- 14. You can mix The Rails Way with The Next Way
- 15. Gradual changes
- 16. start with service objects
- 17. service objects are the gateway drug
- 18. Gradually reduce the Rails magic
- 19. Magic is bad
- 20. We’re software developers, not software magicians
- 21. Turn implicit into explicit.
- 22. Turn conventions into explicit code
- 23. Don’t Repeat Yourself We went too far with this rule.
- 24. Coupling is worse than code duplication
- 25. DRY examples • It’s OK to have different User classes for authentication, storage and for presentation • It’s OK to duplicate some code in controllers/services instead of relying on the controller filters
- 26. The Next Way is just one possible set of techniques
- 27. Other alternatives • DCI / Clean Ruby • CQRS • Event Sourcing • Ports & Adapters
- 28. Choose what’s best for your project
- 29. Experiments are OK (as long as you keep the app working)
- 31. small steps
- 32. Your tests should be green all the time
- 33. Learn how to refactor without any fear.
- 34. Rails Refactoring recipes • Inline controller filters • Explicitly render views with locals • Extract render/redirect methods • Extract a SingleActionController class • Extract a routing constraint • Extract an adapter object • Extract a repository object • Extract a service object
- 35. Thanks! “Fearless Refactoring: Rails Controllers” http://rails-refactoring.com still on a discounted price! (1.0 available from December 1st)