[LRUG] Evaluating Hexagonal/SOLID Principles in Rails

[Paul Mucur]

This idea of trying to implement an application or even a sliver of
one in various different styles almost as a kata exercise is appealing
to me. You're right that the difficulty is in picking a relatively
atomic feature to implement but if we get that right it'd be very
interesting to compare them. (See Gary Bernhardt's screencast on
mutation with "Tell, Don't Ask" [0] for a small example of this.)

I agree that finding a hard metric is likely impossible but it'd be
interesting to have guiding questions with which you could interrogate
your code. As a specious example, if you were forced to ask "how much
code would I have to change if a certain dependency's interface
changed?" then maybe that could help course correct earlier.

I think my crime was to apply principles such as SRP and Dependency
Inversion almost blindly with no thought as to how it actually
improved my specific use-case.

[0]: https://www.destroyallsoftware.com/screencasts/catalog/mutation-in-tell-dont-ask

On Tue, Jun 19, 2012 at 2:33 PM, David Burrows
<david at designsuperbuild.com> wrote:
> 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
>
>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>