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 new features

• Possible to turn a prototype into proper production app

Because of The Rails Way

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

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?”

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

When is The Rails Way bad?

• advanced developers

• complex business logic

• long-living business processes (like order)

• multiple teams

• predictable speed of work

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 duplicate some code in controllers/services instead of relying on the controller filters

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 methods

• Extract a SingleActionController class

• Extract a routing constraint

• Extract an adapter object

• Extract a repository object

• Extract a service object

Thanks!

“Fearless Refactoring: Rails Controllers” http://rails-refactoring.com

still on a discounted price! (1.0 available from December 1st)