DHH is sceptical about many things :)<div><br></div><div>Thing is, I've never seen these things as rules and 'constraints'. </div><div><br></div><div>If you see things as guiding principals when you're refactoring code, they'll make a lot more sense. If you're just moving something to another file for the sake of it, it's pointless - "<span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">it had lost </span><span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">significant meaning: I had simply pushed the code into another file" was the most telling thing you said.</span></div>
<div><br></div><div>I try and code by a few principals:</div><div><br></div><div>1. Code must communicate - objects should have some role in your domain & methods should describe specific interactions</div><div>2. Don't dig into object hierarchies - interact via top-level interfaces</div>
<div>3. Apply these principals while refactoring - don't try and imagine how everything needs to fit together</div><div><br></div><div>Patterns in these cases become tools for achieving this - not some big law or constraint. </div>
<div><br></div><div>Some folks have taken this to it's logical conclusion - start with a single ruby file and only add complexity as the features/refactoring demands. This is great, but you can still apply these principals when writing a Rails app - and you'll be really thankful when it grows to significant size.</div>
<div><br></div><div>Examples etc are sometimes hard because they just look trivial but I look back at 6 years of legacy Rails that I wrote - and are still active development - and these things just scream out.</div><div><br>
</div><div>Steve</div><div><br><div class="gmail_quote">On Tue, Jun 19, 2012 at 10:08 AM, Paul Mucur <span dir="ltr"><<a href="mailto:mudge@mudge.name" target="_blank">mudge@mudge.name</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Good morning all,<br>
<br>
During my commute this morning, I finally had an opportunity to listen<br>
to the Ruby Rogues' interview with David Heinemeier Hansson [0] and I<br>
wanted to stir up some discussion on the list regarding some of what<br>
DHH said re the recent interest in "Hexagonal Rails" [1], Dependency<br>
Inversion [2], etc. within the community.<br>
<br>
At the risk of paraphrasing him incorrectly, DHH seems highly<br>
sceptical of any improvement offered by tools such as Objectify [3] or<br>
even design principles such as SRP or Law of Demeter as he uses only<br>
one measure of quality: whether the code looks better with or without<br>
the tool/principle applied.<br>
<br>
Of course, defining "looks better" is highly subjective (and Tom<br>
Stuart posited an extremely interesting theory during his talk [2]<br>
that the pursuit of "beautiful code" in Ruby is damaging) but I think<br>
there is an uncomfortable truth buried in here: that maybe we do need<br>
to prove that code after redesign/refactor is *measurably* better than<br>
the old. I fear that simply stating "it's more maintainable" without<br>
demonstrating the fact is too vague and can be dismissed, as DHH puts<br>
it, as "fortune telling".<br>
<br>
Yesterday, I experimented with refactoring a controller ala Matt Wynne<br>
and Steve Tooke's example [1] at our last meeting (but with some<br>
mistakes as you'll see). By the end of the first pass, I had initially<br>
pushed some of the complexity into Responders rather than leaving it<br>
all in the controller. At first, this seemed like an improvement<br>
because the controller was decidedly skinnier but it had lost<br>
significant meaning: I had simply pushed the code into another file,<br>
thereby hiding it rather than simplifying the design.<br>
<br>
e.g.<br>
<br>
require_relative "../responders/article_responder"<br>
<br>
class ArticlesController < ApplicationController<br>
respond_to :html, :json<br>
<br>
def index<br>
respond_with(current_user, responder: ArticleResponder)<br>
end<br>
end<br>
<br>
Worse still, the Responder inherited from ActionController::Responder<br>
so it offered no decoupling from Rails at all. I had obviously lost<br>
sight of what I was originally trying to do. This made me wonder; what<br>
*real* metrics can we use to both steer and measure the quality of our<br>
designs? To simply state "looser coupling" or "adherence to the Single<br>
Responsibility Principle" seems to be arguing at the wrong level:<br>
these are both purportedly qualities of better code but what do they<br>
truly enable? An obvious and practical answer might be "easier major<br>
Rails upgrades" but I'd be keen to hear your thoughts.<br>
<br>
Don't misunderstand me: I believe that separating your application's<br>
core logic from your particular framework is a Good Thing but I feel<br>
like we need more worked examples exploring the realities of creating<br>
applications in this style such as James Hunt's recent "Building a<br>
Rails app without Rails" [4].<br>
<br>
I grow increasingly convinced that these principles are not something<br>
that Rails or even Objectify can help us with as the key is to change<br>
how we should build and design our applications *regardless of<br>
framework*. This is particularly evident to me having co-authored<br>
Proffer [5] which was an attempt to mitigate a bad practice with<br>
tools. Perhaps the best thing we can do as a community is not to<br>
constrain with software but to focus on *education* and examples?<br>
<br>
-- mudge<br>
<br>
[0]: <a href="http://rubyrogues.com/056-rr-david-heinemeier-hansson/" target="_blank">http://rubyrogues.com/056-rr-david-heinemeier-hansson/</a><br>
[1]: <a href="http://skillsmatter.com/podcast/ajax-ria/hexagonal-rails" target="_blank">http://skillsmatter.com/podcast/ajax-ria/hexagonal-rails</a><br>
[2]: <a href="http://skillsmatter.com/podcast/ajax-ria/dependency-injection/js-4123" target="_blank">http://skillsmatter.com/podcast/ajax-ria/dependency-injection/js-4123</a><br>
[3]: <a href="http://jamesgolick.com/2012/5/22/objectify-a-better-way-to-build-rails-applications.html" target="_blank">http://jamesgolick.com/2012/5/22/objectify-a-better-way-to-build-rails-applications.html</a><br>
[4]: <a href="http://ohthatjames.github.com/2012/06/17/rails-without-rails/" target="_blank">http://ohthatjames.github.com/2012/06/17/rails-without-rails/</a><br>
[5]: <a href="https://github.com/hudge/proffer" target="_blank">https://github.com/hudge/proffer</a><br>
_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</blockquote></div><br></div>