1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
|
---
layout: post
title: Extract your business
tags: [ development ]
published: true
---
I've come to realize one big factor to consider when building Ruby apps.
I've given a [talk at
AgilePT](http://2012.agilept.org/program/invited-talks#toc-anchor-4034-10) on
how agile is Ruby on Rails. I should know better than just encouraging
businesses to adopt Ruby and Rails into their development. There's one thing
that so many people face and most of the time evangelists discard:
_regression_.
I love working with Rails, it's a living organism. It's in its nature to
survive, it won't stale like most software tends to at some point. However,
because of that it's important to consider its volatility. _How is a product
supposed to follow the ever so changing nature of the framework_?
Why isn't your business a gem of its own?
-----------------------------------------
The business of a product is as important as the tools you use, perhaps even
more important. As product owners we ought to care more on how our business
logic is managed. The good thing about Rails is that it's so well organized and
its conventions are so straightforward that it's not really that hard to set
your logic apart from the framework.
If you care enough about your product and also you constantly strive for
innovation and early adoption, then it's best to protect your software from the
framework, not just because Rails is often patched and upgraded with new
features over time but also because it allows you to change more easily.
It's totally acceptable to acknowledge you might not be into Rails anymore, or
perhaps there's a feature in the framework you're not so fond of and you wish
to defy standards by adopting a different solution for a certain problem:
* You might not be into SQL anymore and you want to switch to Couch, Mongo or
any other database;
* Perhaps you have a different way of persisting data like Hibernate (if you're
using JRuby);
* You want to improve performance by tweaking the frameworks' defaults.
* How about extracting your app into a JSON API and go heavy on Javascript?.
Change is always imminent. I learned that the hard way and Ruby now gives me
confidence upon change. TDD is an awesome leader that _accepts change as a
reality and no longer a challenge_. Also, it provides guidelines to better app
design and that increases maintainability.
The framework should only support common tasks, that's why it's called a
framework. All the MVC paradigm, boilerplate, persistence, helpers, templating
and email can be handled by Rails, _it can be safely upgraded without
compromising your business logic_. It will be my personal goal to improve on
this as I have a lot to go through yet.
|
