Rails wayにどこまで従うべきかという議論

http://andrzejonsoftware.blogspot.com/2014/04/be-careful-with-rails-way.html

1 comment | 1 point | by WazanovaNews 2年以上前 edited


Jshiike 2年以上前 edited | ▲upvoteする | link

RailsでInteractorをうまく利用する」と「DHHとのピンポン」で紹介した議論をうけて立ち上がったサイト( http://www.dhh-ping-pong.com/ )で、DHHに挑戦するコードのピンポンが行われてます。

最初に取り上げられたAndrzej Krzywdaとのやりとりは、こちら。Andrzejのリファクタリングについてのオリジナルのブログはこちら

また、Andrzejは最新のブログの投稿で、その比較について解説しています。

  • 自分はコードとRailフレームワークとの関係をなるべく疎にすることで、リファクタリングしている。controll filterとmodel callbackは避ける。DHHは逆で、filterもcallbackも利用している。
  • また、レポジトリのパターンも利用することで、目的としてはロジックのフレームワーク依存をなくすこと。データベースをヒットすることなくテストの実行も早くなる。アプリを小さな単位にわけることができる。アプリ全体をコントロールしやすくなる。Railsの世界では標準でなくても、Java, .Net, Scala, Clojure, Haskell, PHP (Symfony2 framework)など他のコミュニティではそれほど特別なアプローチではない。
  • Railsは最初はよくても、コードが肥大化したときのことを考えると、Railsのフレームワークに頼ったままのコードでは、分割/追加するときに自分でコントロールできなくなる。例えば、新しい要件が追加されて、実際はdomain modelが必要で、ビジネスロジックを担保し、他のroleからデータを隠さなくてはいけないとしよう。そのケースが、Railsのチュートリアルに載ってなかったらどうなるのか。この瞬間がまさにKent Beckの言うように、依存したデザインでなく小さな単位のデザインがよいということである。
  • 長期的に大きなRailsのコードベースを扱う際に良いと思われる一つの方法を提示している。これしか方法がないと言っているわけではない。Rails wayに全て従うのでなく、一般的なプログラミングの習慣に倣っているだけである。全てRails wayに頼ってしまうと、片道切符になる。

#rails

Back