CTCと夜の決闘

昨日、CTCに「お前は最近、Railsに批判的でけしからん」ということで、呼び出されました。もちろん、「批判的でけしからん」というのは冗談ですが、私が、Railsを嫌っていると思っているRuby関係者は、実際多いようです。
「JavaからRubyへ」の本に対して、それはちょっとおかしいんじゃないのといったことはありますが、Railsを嫌いといったことはもちろんないはず。

呼び出されたのは、Rubyの話じゃなくて、Javaの社内フレームワークの話でした。
Struts、Spring、独自データアクセスフレームワークの生産性を何とかして改善したいという悩みでした。裏を返せば、今が低いと思っているということでしょうね。
あるいは、生産性が低いというより、大手SIerにとって必須の大規模開発をするのには、つらいということなのかもしれません。

CTCの話だと、SAStrutsを使えればいいんだけど、Springベースなので使えないとのことです。同じような話をおとといNTTデータともしたなぁ。NTTデータの場合は、Struts、Spring、iBatisです。
Struts、Springベースの社内フレームワークの生産性を改善しなければならないという悩みを大手SIerから二日連続で聞くことになるとは。

Struts、Springベースの社内フレームワークの生産性があがらない、大規模開発でつらいというのは、ある意味し方のないことです。もともと、生産性を上げるために作られたフレームワークじゃないから。

Strutsは、Servletベースの開発にMVCというアーキテクチャパターンを持ち込み、定型化しました。Struts以前のばらばらだった開発スタイルをMVCで定型化したのです。実際は、Sunのblueprintアプリケーションの中にすでにMVCは取り入れられていたので、それをフレームワーク化したというほうが正確かもしれません。
Strutsは、生産性を高めるために作られたものではないのです。

Springは、POJOベースの開発をもたらしました。EJBに苦しんでいた開発者を救ったのです。POJOベースの開発は、テストのしやすさというメリットをもたらしますが、生産性そのものは改善しません。普通のJavaのクラスでかけるようになっただけだから。EJBに比べると生産性はずっといいんだけど。

生産性を向上させるということを主目的としてフレームワークが作られたのは、基本的(もちろん例外はあるけど)にRails以降のフレームワークです。
Railsは、Struts、Spring、Hibernateへのアンチテーゼとして登場しています。裏を返せば、Struts、Spring、Hibernateを組み合わせても生産性は出ないということです。

じゃ、どうすればいいのかというと、SAStrutsをベースにSpringでも動くように修正するといいのではないでしょうか。SAStrutsは、実質的な(例外だとかアノテーションを除いた)クラス数は40位と小さいので、移植するのは難しくないはずです。
移植する中で疑問があれば、いつでも私が答えますよ。
Springは、2.5からコンポーネントの自動登録に対応したので、HOT deployができないことを除いては、Seasar2と同じように使えるはずです。