RADツールの可能性：設定から規約

アジャイルソフトウェア開発について前回書きました。
2009年Ver1でスタートしたSpring　Rooは本格的なRAD（Rapid Application Development）ツールです。
現在Javaでの開発手法として一番有望な技術だといえます。

2003年頃日本ではSpringフレームワークがJavaのDIコンテナやAOP注目され始めました。初期はXMLでの設定が複雑になりすぎて、この欠点からもう一つのDIコンテナとしてSeaserという技術が沖縄から発信されていました。
私も勉強しようとして両方に関する書籍を購入しましたが、現実的にユーザの実装で使うにはまだ時期尚早で、自己流のフルスタックのフレームワークをStrutsと組み合わせて使っていました。

現在、Springも１０年を超えました。APIも体系も膨大な資料になりました。
今ではJavaのサーバフレームワークの代名詞がSpringになりました。
Java言語も確かチューニング完全宣言がアナウンスされました。
このような良い意味で枯れた技術を基盤として現れたのが、Spring　Rooと考えています。
元々フルスタックのサーバサイド技術がない為にSpringが登場したわけですが、Sunの技術があまり浸透しないで、RADツールとしてRooが生まれました。
どうやらこの技術が成功したら、PHPの開発も同じツールでカーバしてくれるようです。

このツールの本質は、「設定よりも規約」です。XMLやJavaで実装パラメータを設定したことに限界を感じて、次世代技術として規約が注目されたわけです。
設定もマクロ化して考えれば、単に規約に集約されると言えるので、非常にリーズナブルな概念であると思います。

私はかねてからオブジェクト指向技術は基盤であって、上位設計での技術ではあまり活用できないと信じてきました。決して基盤でのオブジェクト指向技術を否定しているわけではありません。
上位設計では理論よりも効率と正確性を強く求めています。又最も要件としてあるのはコミュニケーションでしょう。
Rooはこの要求に一歩近づいた考え方であり期待できる技術であると考えています。
欠点は、一度動作に問題があるとほとんどが自動化されていて、技術的基盤自体が巨大なAPI体系で構成されている為、解決することが難しいと思います。

---

開発の容易性では、他の言語でも検討しなければいけませんが、RubyとPHPが日本では主流です。Pythonも同じカテゴリですが、海外ほど利用者が少ないのが現状です。ここで正確には以下説明のRubyとPHPは、MVCの体系を指しています。

Ruby on Railsは、「同じことを繰り返さない」コンセプトです。ネットでの評判はかなりの支持者がいます。RubyDocサイトを訪問してみましたが解り易く、利用しやすいドキュメントでした。利用者側の意図を組み入れている内容でした。

CakePHPは、やはり海外のサイトですので、英語のドキュメントで７５０ページ程度のものがありました。やはり日本語がいいのですが、元々解り易い言語なのであまり問題視しなくても良いかもしれません。

3つを同じ目線で比較すると、RooはバックグラウンドのJavaが体系が膨大で、色々考慮する内容が多すぎて、Java+Spring＋SpringRooの３層になっています。
RubyとPHPは元々開発のし易さが売りなので、２層になっていると考えられます。

 以上、今後の動向を注目するべき内容と思います。