[LRUG] Evaluating Hexagonal/SOLID Principles in Rails

[Steve Tooke]

Hi Paul,

On Tue, Jun 19, 2012 at 10:08 AM, Paul Mucur <mudge at mudge.name> wrote:
> maybe we do need
> to prove that code after redesign/refactor is *measurably* better than
> the old. I fear that simply stating "it's more maintainable" without
> demonstrating the fact is too vague and can be dismissed, as DHH puts
> it, as "fortune telling".

I'm not sure we can find a metric, as 'maintainability' is function of
the cost to modify the existing behaviour of the application, and I
think that is an estimate based on the state of the code now.

I wonder if its worth looking at this another way. I recently read a
post [1] by J.B. Rainsberger which explains how TDD works using the
theory of constraints, in particular queuing theory. He takes this
idea:

"Given a process B, which follows a process A, sometimes in performing
B we need to perform some of A again. We can remove the need to rework
by taking some portion of process B and performing it before process
A."

In the post he uses this idea to pull Analyis, Testing, Coding and
Design in to a tight feedback loop, and he describes this as Behaviour
Driven Development.

The important thing is where design sits in this loop - after
coding... or before you start adding the next feature. This is because
"we can remove the need to rework by taking some portion of process B
and performing it before process A." So by cleaning up our design,
after we code it - and before we start adding more features, we should
make adding new features easier.

Unfortunately because this is software we don't have much in the way
of studies to back up this claim, but we do have our own experiences.
How much quicker does it feel to add behaviour to a system which is
loosely coupled - where there are clear seams to add new behaviour?

> Don't misunderstand me: I believe that separating your application's
> core logic from your particular framework is a Good Thing but I feel
> like we need more worked examples exploring the realities of creating
> applications in this style such as James Hunt's recent "Building a
> Rails app without Rails" [4].

I totally agree - I'm looking forward to see how James' and Roland's
approach works!

> I grow increasingly convinced that these principles are not something
> that Rails or even Objectify can help us with as the key is to change
> how we should build and design our applications *regardless of
> framework*. This is particularly evident to me having co-authored
> Proffer [5] which was an attempt to mitigate a bad practice with
> tools. Perhaps the best thing we can do as a community is not to
> constrain with software but to focus on *education* and examples?

Yes! Build your application in a way that lets you really focus on
delivering the behaviour you need. Use the frameworks to support you,
to make things easier in the areas that they are good at - but don't
put them at the heart of your application.

[1] http://www.jbrains.ca/permalink/how-test-driven-development-works-and-more

-- 
/tooky