まず、まとめ
- Rails でも View にかかる工数はあまり変わらない。
- web 2.0 っぽいリッチな画面は技術リスクが高いので、思ったより高くつく
どうも、上記ふたつの点で計画との乖離が大きくて、失敗するケースが多い。
Rails なプロジェクトの場合、俗に言う web 2.0 の文脈からか従来よりリッチな画面を要求されがちである。
確かに、Rails はそういうアプリケーションの作成には、非常に向いていると思う。
しかし、どうして向いているのかを考えてみると、大きな理由として、Rails では従来 Model と Controller に必要だった工数を大幅に削減できるため、その分の工数を View に回せるからだと僕は思っています。
prototype.js や script.aculo.us などの有用なライブラリや Try and Error のしやすい環境で View の開発ができるというメリットもありますが、Rails だからといって昔と比べて劇的に開発効率が高くはなってない気がする。*1
実際に、Model, Controller を瞬殺できるけど、どうしても View は Rails での開発のボトルネックになっていると思う。
なので、バックエンドの処理で色々と要求されるプロジェクトの場合は、View に回せる工数は必然的に少なくなるので、そういったプロジェクトの場合は無理せず、web 1.0 っぽい画面でやるべきでしょう。
また、リッチな画面が必要な場合にもリスクを正しく認識すべきだと思っています。
Flash はあまり経験が無いので対象外としますが、リッチな画面を HTML + CSS + Javascript で提供する場合、僕のようなフツウのプログラマでは結構大変だったりします。
その理由としては、こんな感じ
- Developer Testing できない
- IE ではデバックすら困難
- クロスブラウザ対応はバッドノウハウの宝庫
これまでサーバ側で実装していたようなロジックが View 側に寄ってきている気がしています。
しかし、View 側での開発ではサーバ側のように xUnit で簡単にテストという訳にはいかず、デバッグすら困難という状況です。
また、開発しやすい設計パターンのようなものもそんなに浸透していません。
そういった状況では、僕のようなフツウのプログラマでは結構厳しいと思っています。
確かに Effect やちょっとした部分に Ajax などを使うといった事はすごく簡単にできるようになりましたが、実案件ではやはりその程度で ok という訳にはいきません。
なので、 web 2.0 っぽい画面は思っている以上に高価なものという認識が必要だと思いますし、そういう認識が発注側に無い場合は気をつけた方が良いと思います。
*1:さすがに deploy に数分かかって、画面を確認するなんて時代には戻れないけど ;-p