 |
||||||||||||||||
|
||||||||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||||||||
|
||||||||||||||||
| Railsのメリット | ||||||||||||||||
|
ここからはもう少し突っ込んでRailsで得られるメリットを具体的に見てみましょう。 より開発現場への直接的なメリットであることを確かめるために品質・コスト・納期の観点を織り交ぜて説明します。 |
||||||||||||||||
| 強力なコード量の削減 | ||||||||||||||||
|
コストを削減するための方法としては、開発工数を減らすことがあげられます。そして工数を減らすためにまず思いつくのは、ソースコードの量を削減することです。 ではRailsによる開発では、ソースコードをどのくらい削減できるのでしょうか。 そこで同じ内容のコードをHibernate（Java EEのO/Rマッピングフレームワーク）とRailsで作成してみました。その結果をビジュアル的に比較したものが図1です。  図1：RailsとHibernateのステップ数比較 Railsが多くの支持を得ている理由を体感できましたでしょうか。コード量はステップ数で1/100にもなっています。読者の皆さんもお察しの通り、これはとても極端な例です。 Java EEにおける開発では、Eclipseやその他ツールでこれらのソースコードの大半を自動生成することができますし、システムの規模が大きくなるほどO/Rマッピング記述部分の全体に占める割合は減っていくわけですから、決して最終的な記述ステップ数が1/100になるわけではありません。記述すべきロジックはより業務的にコアで複雑なものになってきますから、ステップあたりの平均工数は逆に増加するでしょう。 ただ、ソフトウェア開発では要件変更や設計ミスなど何らかの都合で一度作ったものに手が入ることはよくあります。修正が入る場合、大量に自動生成されたコードの紐付けを保ちつつ修正するのと、小さなコードを直すのとどちらが楽なのは自明なのではないでしょうか。これは保守段階のメンテナンス性のことを考えても同様です。 また、自動生成であっても作成したソースコードはすべてテストすべきという考え方もあります。 直接的な話ではありませんが、ソースコードの量を削減することは自動生成できる部分であっても様々な弊害を回避して、全体の工数を下げる有力な手段であるといえるのではないでしょうか。 ちなみに以前筆者が簡単な書籍管理のサンプルシステムを作った時にはJava EE（Struts + Spring Framework + Hibernate）と比べてステップ数が1/9程度になりました。XMLやデータ転送用のJavaBeansがまったく必要ない点で大きく差がついたのです。 |
||||||||||||||||
| Ajaxライブラリの標準装備 | ||||||||||||||||
|
近年、使用性や効率性といった品質特性（ユーザビリティ）を向上させる技術として注目されているのがRIA（Rich Internet Application）、つまりはリッチクライアントです。 そしてご存知の通り、RIA技術の一種であるAjaxがここのところWeb2.0とともに話題です。 Railsでは表3に示す通り「prototype.js」「script.aculo.us」というAjaxライブラリを同梱／統合しており、簡単なタグを書くだけで様々な機能を利用することができます。
表3：Railsに同梱されているAjaxライブラリ 玉石混交のAjaxライブラリが乱立している現在、すぐに利用できる標準ライブラリが準備されているのは選定コストの削減という意味で大きな強みであり、積極的なRIA適用の源泉となるでしょう。 |
||||||||||||||||
| フルスタックの提供 | ||||||||||||||||
|
納期遅延のよくある原因はリスクの見誤りです。例えば、利用ライブラリの動作検証を甘く見ていて開発後半で思わぬ手戻りや停滞が発生するなどが典型的でしょう。 アプリケーションが様々なOSS（オープンソースソフトウェア）製品から構成されている場合では、相性に関する検証項目は掛け合わせ的に増加するため、どうしても十分な検証を行えないままにプロジェクトが進むこともあるのではないでしょうか。 しかしRailsはフルスタックです。つまり、Railsのみで画面周りからデータベースアクセス、さらにはテストやジェネレータ、開発用サーバ、Webサービスなどすべてが同梱されています（図2）。  図2：Railsはフルスタック （画像をクリックすると別ウィンドウに拡大図を表示します） このことで相性問題の発生を大幅に削減することができます。また、問題が発生した場合の切り分けも容易になり、納期遅延の抑制に一役買えるわけです。 もちろんアーキテクチャ的には分離されているため、他の優れた製品を用いたい場合にはそれなりのリスクを見込んだ上で各スタックを入れ替えることもできます。 |
||||||||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||||||||
|
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
-
-
連載
