Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Beyond 
The Rails Way 
Andrzej Krzywda 
http://rails-refactoring.com
Why is Rails 
business-friendly? 
• Quick to produce a prototype 
• Prototypes are production-ready enough 
• Easy to add ...
Because of The Rails Way
Why is Rails not business-friendly? 
• Because of The Rails Way 
• Business loves the speed of adding new features 
• … bu...
The Rails Way 
• Scaffold-like code in controllers/views 
• ActiveRecord goes all the way up to the view 
• features imple...
When is The Rails Way 
good? 
• for business/coding people to prototype 
• for less-experienced developers 
• to quickly g...
When is The Rails Way bad? 
• advanced developers 
• complex business logic 
• long-living business processes (like order)...
If not The Rails Way 
then what?
Beyond 
The Rails Way
The Next Way
The Next Way 
• service objects 
• repositories 
• form objects 
• adapters 
• domain objects 
• events
The Next Way is heavily 
influenced by DDD and classical 
OOP patterns
It’s not all or nothing
You can mix The Rails Way 
with The Next Way
Gradual changes
start with service objects
service objects are the 
gateway drug
Gradually reduce 
the Rails magic
Magic is bad
We’re software developers, 
not software magicians
Turn implicit into explicit.
Turn conventions 
into 
explicit code
Don’t Repeat Yourself 
We went too far with this rule.
Coupling is worse 
than 
code duplication
DRY examples 
• It’s OK to have different User classes for 
authentication, storage and for presentation 
• It’s OK to dup...
The Next Way is just one 
possible set of techniques
Other alternatives 
• DCI / Clean Ruby 
• CQRS 
• Event Sourcing 
• Ports & Adapters
Choose what’s best for your 
project
Experiments are OK 
(as long as you keep the app working)
Make safe changes
small steps
Your tests should be green 
all the time
Learn how to refactor 
without any fear.
Rails Refactoring recipes 
• Inline controller filters 
• Explicitly render views with locals 
• Extract render/redirect m...
Thanks! 
“Fearless Refactoring: Rails Controllers” 
http://rails-refactoring.com 
still on a discounted price! 
(1.0 avail...
Upcoming SlideShare
Loading in …5
×

Beyond The Rails Way

3,110 views

Published on

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?

Published in: Software

Beyond The Rails Way

  1. 1. Beyond The Rails Way Andrzej Krzywda http://rails-refactoring.com
  2. 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. 3. Because of The Rails Way
  4. 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. 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. 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. 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. 8. If not The Rails Way then what?
  9. 9. Beyond The Rails Way
  10. 10. The Next Way
  11. 11. The Next Way • service objects • repositories • form objects • adapters • domain objects • events
  12. 12. The Next Way is heavily influenced by DDD and classical OOP patterns
  13. 13. It’s not all or nothing
  14. 14. You can mix The Rails Way with The Next Way
  15. 15. Gradual changes
  16. 16. start with service objects
  17. 17. service objects are the gateway drug
  18. 18. Gradually reduce the Rails magic
  19. 19. Magic is bad
  20. 20. We’re software developers, not software magicians
  21. 21. Turn implicit into explicit.
  22. 22. Turn conventions into explicit code
  23. 23. Don’t Repeat Yourself We went too far with this rule.
  24. 24. Coupling is worse than code duplication
  25. 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. 26. The Next Way is just one possible set of techniques
  27. 27. Other alternatives • DCI / Clean Ruby • CQRS • Event Sourcing • Ports & Adapters
  28. 28. Choose what’s best for your project
  29. 29. Experiments are OK (as long as you keep the app working)
  30. 30. Make safe changes
  31. 31. small steps
  32. 32. Your tests should be green all the time
  33. 33. Learn how to refactor without any fear.
  34. 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. 35. Thanks! “Fearless Refactoring: Rails Controllers” http://rails-refactoring.com still on a discounted price! (1.0 available from December 1st)

×