自分はこんな感じでRailsアプリを作っております


Railsを使い始めてX年経ったこともあり、自分なりの開発パターンが形成されていることに気づきました。今日はそれを恥ずかしげもなく晒してみようかと思います。

Gemfile

自分の中で必須のgemたちです。その他はプロジェクトに合わせ適宜追加する感じです。

パフォーマンスは絶えず確認する

rack-mini-profiler というgemを使用して、常にパフォーマンスを確認しながら開発してます。SQLの発行数も確認できるのですごく便利。詳しくは過去の記事で説明してます。

rack-mini-profiler

検索はransackで

単純な検索機能であれば、 ransack を導入することで大した手間なく実現できてしまいます。

ransack

たったこれだけで、検索機能が完成しました。

ViewModel層を作る

draper を導入すれば、簡単にViewModel層を追加することができます。オブジェクト指向的に実装できますし、ビューやヘルパーがごちゃごちゃしなくて済みます。詳細はRailsCastが分かりやすいと思います。

RailsCasts - #286 Draper

decorator

(サンプルがViewModel層として、うってつけではないですね。すいません・・・)

複数モデルを更新する場合はFacadeで

単純なマスタメンテナンス機能なんかは、scaffoldと同等のコードで構わないと思います。しかし、アプリがある程度の規模になってくると、一連のトランザクションで複数モデルを更新する場合が出てくると思います。そんなときは、facadeクラスを用意します。

Facadeを呼び出すコントローラ側は、すごくスッキリします。

J2EEでいうところのServicesですかね。

テストは rspec + shoulda-matchers で

shoulda-matchers を使用すれば、いくらかのspecが簡単に書けます。一番役に立つのはバリデーションのspecかな。

例えば以下のようなモデルに対して・・・

簡単にバリデーションのspecが書けちゃいます。

単純なバリデーションにまで、いちいちテストを書くのかどうかは意見が分かれると思います。しかし、shoulda-matchersを使えば1行でサクッと書けるので、私はテストするようにしてます。

shoulda-matchers

ヘルパーのテストは書かない

特定オブジェクトに属する複雑な表示処理は、前述の draper にてViewModel層に定義し、テストを書いています。よって、ヘルパーには大したコードが残らない & どうせ目で見て確認しないとダメ なので、ヘルパーのspecは書いてません。

ビューのテストも書かない

昔書いてましたが、あまりメリットが無かったのでもう書いてません。私の場合、画面の開発って、あーでもない、こーでもないって考えながら実装していくパターンが多いので、どうしてもテスト・ファーストできません。テスト・アフターで「ブログ一覧と表示されているか?」ってテストするのもアレですし、そもそも体裁を確認するために結局目視するので、書くのをやめてしまいました。

Javascriptのテストも書かない・・・

フロントエンドをJavascriptでゴリゴリするようなナウいアプリなら、当然テストを書くべきでしょう。しかし私は、今のところその手のアプリを作っていません(恥)。また、jQueryでidやクラス指定してゴソゴソするような処理は、実画面のDOM構造と密接に関連して『しまう』ので、テストビューなどを用意した自動テストは上手くハマらないと思います。キモとなる重要なJavascript処理がある場合、 poltergeist でテストするようにしてます。

書くのは models, decorators, facades, controllers, requests sepc

これだけ書いてれば98点ぐらい取れると思います。request specでは capybara と poltergeist で受け入れテストしてます。Cucumberは、フィーチャーファイルを一緒に見てくれるユーザーがいないのでw使ってません。

フィクスチャではなく、factory_girl

ちょっとした規模のアプリになると、フィクスチャは破綻します。最初からfactory_girlを使用するようにしています。

 

以上

 

関連する記事