あるRuby on Railsプロジェクトのふりかえり

昨年末から始めた、Ruby on Rails を使ったある仕事がひと段落したので、ふりかえってみました。

この仕事で作ったWebアプリの詳細は書けませんが、画面数 60、テーブル数 15 と小規模のものでした。システムはところどころに難しい部分はありました、UIは一部に Ajax(JQueryを使用)を導入し使い勝手を高めています。

1. ソースコードが少ない！

書いたRubyコードの行数を合計すると約3600行しかありませんでした！ 1画面あたり 60行しか書いてない !!
・・・「あんまり仕事してないじゃん！」と思わずつぶやいてしまいまました ^^);

やはり、Ruby on Rails は生産性が高いと言われる通りです。

ただし、だらだらとコードを書かないように以下のように注意しました。

共通部分はモジュール化しMix-inで共有

継承による機能の共有は設計が難しくなりますし、委譲による共有はめんどうです。しかし Mix-inは手軽に実装の共有ができます。ほんとうにRuby言語の良さを感じました。

一部の処理はDSLを定義して使う

一部の処理はDSLを定義して、利用する側にはDSLで機能を定義するようにしました。ライブラリーにパラメターを渡して利用する場合に比べると、DSLを処理する側のコードは少し難しくなりますが、利用する側のコードは圧倒的に簡潔になります。メタプログラミング万歳です。

シンプルで効果が高そうな場合は、Ruby/Railsのコアクラスを拡張

Ruby/Railsのコアクラスを拡張すると、アプリケーションのコードは少なくできますが同時に不可思議なバグを作ってしまったり、Railsのバージョンアップで動かないコードを作ってしまう危険性があります。

今回は、コアクラスの拡張はシンプルなものだけに絞りましたが、やはりコードが簡潔になるのは嬉しいですね。
例えば、以下のような拡張をしました

id = params[:id].is_blank? ? nil : params[:id].to_i
# 上のようなコードが頻繁に出てきたので、StringとNilクラスに 
# to_id というメソッドを定義し、以下のように書けるようにしました
id = params[:id].to_id

定義は

module CoreExtentionsForString
  def to_id
    self.blank? ? nil : self.to_i
  end
end
module CoreExtentionsForNilClass
  def to_id
    nil
  end
end

NilClass.send(:include, CoreExtentionsForNilClass)
String.send(:include, CoreExtentionsForString)

2. RSpecでテストを書く

RSpecで(スッペク)テストを書きました。今回も

ロジックはモデルに集約し、コントロラーにはロジックは書かない
したがって、テストはモデル中心
汚いコードはテストが出来たらリファクタリングする
テストは後付でも良いから絶対に書く

という方針でRSpecを書きました。このプロジェクトが初RSpecだったので、なんとテストが約3400行と処理のコードと同じくらいの行数がありました。やや書き過ぎかもしれません ^^);

おかげで、プロジェクト途中でのテーブル構造大変更や Ruby on Railsのバージョンアップを難なく乗り切れました。

3. プロトタイプ

今回の仕事のお客様は、ITに詳しくはありませんでした。また、初めての業種だったので私もなかなかお客様の話ている内容が理解できませんでした。そこで、Railsの特性を活かしプロトタイプを作り、お客様と仕様の打合せをしました。結局３回プロタイプを作りました。

最初のプロタイプは、お客様のやりたい事を私が理解出来ているのかを確認するのが一番の目的になりました。この段階で私の理解が間違っていると確実に、お客様の望みとは違うものを作ってしまいます。

本質的だと思う部分のみを Scaffold等を使ってサクサクと作ってみました。・・・・・・というのは嘘でJQueryで凝ったUIを作るのに時間を使ってしまい ^^); 途中から Scaffoldで作ったシンプルな画面へと方向転換しました。

2番目のプロトタイプは最初のプロトタイプで(時間の都合で)作っれなかった機能を加えたり、最初のプロトタイプにた対する要望を加えたプロトタイプで、この段階でほぼ仕様は確定しました。

3番目のプロトタイプは、納入するシステムの仕様確認という位置づけでした。

プロトタイプを作りお客様と打合せする方法は、

お客様がシステムに要求・期待していることが具体的に出てくるので、間違った方向のシステムを作らずにすむ
お客様に出来てくるシステムのイメージを与える事が出来、お客様に安心感を与える
導入時もプロタイプで知っているシステムなのでトラブルが発生しない

等の良いことだらけだと思います。問題はプロトタイプを作る工数ですが、Ruby on Railsならそうれもだいじょぶです ^^)
また以前書いたオレオレscaffold generator を作るのようにScaffoldの作るコードをカスタマイズする事で同じような画面を量産できるのもRailsの強みです。

まとめ

Ruby on Railsを使うと、プロトタイプを使った開発ができ、お客様の満足度の高いシステムを作る事ができます。

ただし、Ruby on Railsで高い生産性を出すには、Ruby on Railsのベースであるオブジェクト指向、アジャイル開発、メタプログラミング等の知識がそれなりに必要になります。
また、積極的に英語やソースコードから情報を収集する姿勢も重要だと思います。