[LRUG] Evaluating Hexagonal/SOLID Principles in Rails

[David Burrows]

Hi Paul,

I listened to the DHH Rogues podcast lately and had exactly the same
response, especially having recently gone through the Objects on Rails
book. Some of the implementation in the OoR book had such a high overhead
it was hard to believe that they the time was ever going to be paid back.
"Better" is highly subjective but did get me thinking whether we could
create tests for different rails app architectures.

The idea would be to use the different approaches that are being put
forward to build a slightly-more-than-trivial base app (hopefully not
another bloody blog engine) then add a series of features to it that
traditionally cause problems in implementation - things like
authentication, authorisation, social network integration, persistence
backend change etc.

After each feature is added you'd generate some metrics (how many lines of
code are written/re-written to implement each feature, etc.) then move on
to the next one. As long as you implement a decent amount of features it
should become apparent which approaches are keeping complexity down.

Having mulled it over in my head there's obviously a few issues with the
idea, the main one being that everyone would argue about the
implementations. I imagine you could solve that by taking pull requests to
the individual approaches repos - you'd hopefully arrive at an
implementation everyone would be happy with, rather like the re-writes of
benchmarks that always occur whenever a blog post says "X language is 10
times slower that Y"

Anyway, it's been bouncing round my head for a few days, LRUG can feel free
to tell me why it'd never work ;)

Cheers,
David

-- 
David Burrows
079 1234 2125
@dburrows

http://www.designsuperbuild.com/ | @dsgnsprbld



On Tue, Jun 19, 2012 at 11:35 AM, Steve Tooke <steve.tooke at gmail.com> wrote:

> 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
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20120619/edf6b78c/attachment.html>