Rails の規約メモ

偉大なる先輩が教えてくれたrailsの開発ルール

コーディングルール

コントローラのアクションはできるだけ短くする。目標は5行以内

• アクションが長くなってきたら、モデルに切り出せないかを考える。
• モデルにロジックを移すことでstub化しやすくなってテストが書きやすくなる。

モデルの単体テストは必ず書き、Capybaraを使ってエンドツーエンドテストを書く

• コントローラーを短くしてロジックをモデルに切り出しているため、モデルのテストは必ず書く。
• 代わりにコントローラーはただモデルを読んでいるだけなので書かなくても良い。
• コントローラーのテストはCapybaraを使ってエンドツーエンドテストでテストをしても良いけれど、あまり良い思い出はない。
• 管理画面に関しては書かなくても良い(coverageが下がるのは悲しいかもしれないが気にしたら負け)。

before_filterで値をセットしない

• フィルターはあくまでもフィルターなので、値チェックをしてリダイレクトさせたりすることをメインにする。
• アクション全体で使いたいようなインスタンス変数を用意したい場合は、以下のようなメソッドをコントローラに定義する。 （と、書いたものの、同じコントローラー内であれば値セットしても良いかも）

  • すべてのビューやコントローラで全カテゴリを使いたいような場合

helper_method :categories

def categories
  @categories ||= Category.all
end

  RESTをできるだけ守る

• routes.rbに独自のmatchをできるだけ書かない。
• 基本的にresourcesで記述し、イレギュラーなものはmemberやcollectionで書く。これらで表現できないものはHTTPのルールに則ってない可能性があるので見直しましょう

  コントローラにwhereなどを書かない

• 条件文はモデルのscopeに定義して、コントローラではwhereやorderなどをできるだけ直接書かないようにする

  hamlを使う

• 標準のerbではなく、hamlを使って書く。
• デザイナーからはhtmlで貰うが、これをhtml2hamlというhaml付属のコマンドで変換して当て込む

  viewにロジックをできるだけ書かない

• ifやelseを書きそうになったら、helperかmodelかdecoratorを使おう
• そうすることでテストもしやすくなる

  開発者側でCSSをいじりたい場合はdev.cssに書く

• デザイナーからもらったCSSは、原則画像のパスしか変更しない。
• もし開発で追加したいものがあればdev.cssに入れる。
• デプロイする時に最終的に一つのファイルになるのでこれで問題がない。

  独自のオレオレライブラリをプロジェクトに直接入れない

• 作ってはだめということではなく、それが必要ならばgithubで公開してgem化し、bundle installをするのが自然。
• プロジェクトに生のコードを直接入れないでということ。

サービスの品質

プログラムの書き方以外のルール

rake specを通してからリリースする
rake specを忘れずにやる

• 得に複数人の開発では自分の変更点が想定外の影響を及ぼすかもしれない

git flowを使う
http://d.hatena.ne.jp/Voluntas/20101223/1293111549

• 300ms以内にレスポンスを返すようにする
• 遅いサービスはそれだけで悪