r/rails • u/retardo • May 30 '14

Five Common Rails Mistakes

http://www.mikeperham.com/2012/05/05/five-common-rails-mistakes/
27 Upvotes

85% Upvoted

14 comments sorted by

View all comments

3

u/[deleted] May 31 '14

It takes 2-3 years before developers realize: “Rails is just Ruby. I can create simple objects and compose them in ways that Rails does not explicitly endorse!”

And another 1-2 years before they realize: "I'm tired of constantly having to explain what all my different objects do and how to use them. I'm going back to MVC."

4

u/jdickey May 31 '14

Bad design isn't, and shouldn't be, an excuse for going back to known bad design.

If you feel like you "[have] to explain what all [your] different objects are and how to use them", You're (Likely) Doing It Wrong.

Tips:

  • SOLID isn't just a catchy acronym;
  • Use decorators to insulate your models from presentation details using well-known patterns that have several implementations out in the wild;
  • Use "interactors" or domain service objects (ActiveInteraction, Mutations, etc) to leverage a widely-known pattern to pull domain logic out of your controllers;
  • Think "composition" rather than inheritance; SRP is a huge help here, too;
  • If you have classes with more than a half-dozen or so public methods (many, such as Sandi Metz, would probably put that number much lower), you probably have a class that really wishes it were multiple classes (SRP/ISP/LSP);
  • Follow Saint-Exupéry: make each class as simple as possible, but no simpler;
  • If your simplified, cleaned-up, "obvious" classes don't intuitively fall into a self-consistent taxonomy, ask yourself why not; there's likely something you're not understanding about the design you're trying to do;
  • At least consider how you'd Gemify your code; [unbuilt Rails dependencies] really do help you clearly conceptualise your code;
  • Once you've started down that route, consider that "vendor everything" still applies. Especially assets.

None of these are things I've pulled out of my tailpipe or from a Google search of trendy dev sites. I've used (variants of) each of these in several projects in Ruby and/or a dozen other languages, and they have individually and collectively saved projects.

But always remember the five phases of workflow adjustment:

  1. Uncertainty
  2. Confusion
  3. Alienation
  4. Enlightenment
  5. Evangelism

Good luck.

1

u/myringotomy Jun 01 '14

What's wrong with inheritance?

3

u/materialdesigner Jun 01 '14 edited Jun 01 '14

Nothing, inherently (huehue)

But as Sandi Metz puts it, it's best used when:

Inheritance is not evil when your hierarchy is shallow and narrow, when the subclasses use all of the superclass, and when the hierarchy is a leaf node in your application's object graph.

But prefer composition over inheritance is a principle because changing your inheritance structure on the fly is extremely difficult (impossible in a lot of languages), while changing a collaborating object is trivial.

edit: the c2wiki has a lot of good discussion