Railsのファットモデルを考える

今日は10:00-19:00で在宅バイト.

どうも時間の見積と実装時間が合わず微妙な感じです. 5時間と見積もって5時間かかった場合と3時間と見積もって5時間かかった場合では,終わった後の印象がだいぶ違うので長めに見積もるのがいいのかなぁとも感じます.

ファットモデルについて

Railsのファットモデルについて,以前までは「コントローラが太らなければモデルが太ってもいいんじゃないの?」的な発想でしたがさすがにメソッド数が増えまくってくるとモジュール分離はするべきだなぁと感じています. すぐ出来る事として,モデルに書かれたViewとの関連が強いコードを分離するようなDecorator/Presenterパターンを実装することがあるので,これらから始めてみると良さそうです.有名どころのGemだと以下の2つですかね

drapergem/draper · GitHub

amatsuda/active_decorator · GitHub

Railsなどフレームワークを使ってると,使わない時に比べて怠ける部分が出る傾向があるのでActiveRecordにとらわれすぎず,クエリの最適化とかモジュール分離などについて考えるべきだと思います. これについては,以前紹介してもらった記事がファットモデルの処方箋としてかなり良さそうなので本格的に読んで見ようと思います.

7 Patterns to Refactor Fat ActiveRecord Models - Code Climate Blog

Railsは楽な反面,その特性上メンテナンスが大変だったり,プログラマフレームワークを超えた発想をしない(しなくていい?)ため,ある規模を超えると一気に破綻が起きるなんてことが起きてきそうです. そうなってくるとメンテナンス性に嫌気がさした人たちが,静的型付けで規約より設定的なフレームワークを使い出し…なんてことが起きそうですね. とはいえ,今でもphpperlを使っている企業は多くあるので,Railsが全くなくなることは無いのでしょうが.

流行り廃りが激しい分,デザインパターンなど設計に関するノウハウは整理しておいたほうが良いかもしれません.

さてさて

ウィークデーが終わったので週末は研究を進める期間.実験が終わりかけているので論文を書き上げて速いこと研究に決着を付けたいところです.

というわけで明日からも頑張りましょー!