Extracting Rails code

Ryan Carson has published his latest interview with Rails creator: David Heinemeier Hansson, where David mentions, amongst other things, that good frameworks should be extractions and not just abstractions. This isn’t exactly the first time he’s mentioned it, but you might find it interesting to note that he singled out Rails components as being an obvious culprit of high-level component bloat, a part of Rails I’ve noticed that I’ve refactored away from on numerous occasions.

I often hear requests for plugins to help with multi-step forms, and after having just implemented a multi-step checkout process I can tell you it’s definitely not a straight-forward extraction. Just figuring out form validation and storage is hard enough–do you use multiple ActiveRecord classes, one ActiveRecord class or ActiveForm objects; do you store them in sessions, cookies or the database; do you store the objects themselves or just the attributes? I think there’s just too many opinions you’d either have to account for or ignore, and either way it’d probably be better off just documenting the different approaches than a code library to encapsulate them.

On the flip side there were a few great candidates for extractions on that same project, either because I’ve reused the exact same code from a previous project or intend to do so for my next one. These were mainly SimpleAuthorisation, app-wide HTTP password protection for the initial private stage of app development; and AccessibleFormBuilder, used to manage label tags and validation messages.

Spending less time abstracting is something I’m really striving for. The fundamentals are so thoroughly solved in Rails that it’s often not worth the time looking for the perfect plugin–just troop ahead and implement it how ever you can, abstracting and extracting the good bits only after you have it working successfully.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • Ryan Bates

    One thing I like about rails and its community is it seems to follow a lot of Extreme Programming practices. Avoiding unnecessary abstraction goes right along with the practices You Aren’t Gonna Need It and Do the Simplest Thing that could Possibly Work.

    http://xp.c2.com/YouArentGonnaNeedIt.html
    http://xp.c2.com/DoTheSimplestThingThatCouldPossiblyWork.html

    I like to think of it this way: Adding abstraction prematurely is like trying to teach someone how to whistle when you don’t even know how to whistle. In other words, don’t add abstraction until you understand the domain completely; otherwise you are just guessing – shooting in the dark. Abstraction creates flexibility at the cost of complexitiy, and you want to avoid unnecessary complexity. Once you see the direct need for abstraction in your implementation, that is the time to add it through refactoring.

  • http://www.toolmantim.com timlucas

    Thanks Ryan. “Do the the simplest thing that could possibly work” was probably the biggest idea that I liked about Rails, but I love the fact the you don’t hear much harping on about the the “rules”. At the end of the day we’re all trying to solve real problems and spend the least amount of time. Rails doesn’t seem too scary to pick up and learn, but XP on the other hand seems to have quite a barrier to entry. “Rails: Web oriented XP for the rest of us” ?

  • Ryan Bates

    Well, I think Rails does have a bit of a barrier as well, but in a different sense. You have to learn to do things the “Rails Way” or else you will be fighting it and have a terrible time. When I first started using Rails I wanted to do things my way. I wanted more control over the database schema, the naming of the Controller and Model classes, and even the organization of the files. Once I accepted the Rails way of doing things, I found it was such a better method and makes things so much easier. It is amazing how much functionality you can get with such little effort when following the conventions.

    Beyond that, there are many other practices that rails encourages, but doesn’t require. Test Driven Development for example isn’t required, but with Rails it is so easy you might as well try it.

    Sorry for the off topic tangent.

  • Anonymous