Railsによる開発のよくある？話その2

Railsで開発したことのある人でも結構あるパターン？

コマンドをよく知らない

IDEとかでもrakeのタスクが呼び出せたり一覧が見えたりしますが、これはIDEがそのコマンド群に対応しているからであって、もしかしたらIDEは新しいコマンドには対応していないことがあるかもしれません。IDEによって分かりやすくなる部分も多いのでIDEを否定する気はありませんが、ターミナルやコマンドラインを直接使うことをオススメします。

で、少なくとも

rake -T
ls script/
ruby script/generate
ruby script/console

を実行して、どんな機能があるのかを確認しておいた方がいいでしょう。

特にscript/consoleは絶対試しておいて損はありません！

また、

rake -T db

で絞り込めることや、

ruby script/generate scaffold

でヘルプが出ることなども知っておくと便利です。

ちゃんとバージョン管理された環境で開発しているのなら、意図していないコミットをせず、何かあってもバージョンを戻せばいいのです。
どんどん試していきましょう。

マイグレーションを使わない

マイグレーションはちょー強力です。使わない理由が「慣れてないから」というのなら、ここだけは慣れていくべきです。おそらく通常のDDLを書いている人ならば、それほど慣れるのに時間はかからないはずです。

たまーに聞くのがチーム内で連携が取り難いからという理由なのですが、それはマイグレーション以前の問題です。チーム内で連携が取り難いならマイグレーション以外の部分も取り難くなっているはずです。どんどん声出していきましょー

ただしチームの規模によって、マイグレーションを誰が書くのかが変わります。

もしチームがそれぞれにマイグレーションを書いて報告し合う形でも整合性が保てるのならばDBAは必要ありませんが、規模が大きく各自に任せると整合性が保てないのならばDBAがいた方がいいでしょう。

テストを書かない

Railsの標準的なテスティングフレームワークでもRSpecでも単体テストは書くべきです。しかし、これはチームのスキルによっては大きく開発を遅らせることになりえます。そこで無理にテストにこだわってプロジェクトが失敗してしまったら意味がありません。

しかし、Rubyには静的な型チェックがないので、Ruby + Railsだけでは本当に動作するのかどうかを担保できません。ちゃんと動く！という安心を得るために是非テストを導入していただきたいですが、そのハードルは決して低いものではありません。

ですので、テストに慣れていない場合は以下のようなステップを踏むといいかもしれません。

script/consoleでモデルの振る舞いを確認してみる
test/unit あるいは spec/models にモデルのテストを書いてみる
フィクスチャを使ったテストを書いてみる
mockやstubを使ったテストを書いてみる（RSpec）
コントローラのテストを書いてみる
ビュー／ヘルパーのテストを書いてみる

いまならRSpecから入ることを強くお進めします。

テストを書かされている感じだと結構しんどいものがあるので、Railsに慣れた後、次のプロジェクトではコードを書き始める前にRSpecとRCovを導入して、

rake spec:rcov

で100%をキープする楽しさを感じでほしいです。

また、ZenTestもインストールして、

ruby script/autospec

で、テストを書いて、コードを書いて・・・というTDDも気持ちよさも感じてほしいっす。