CTCと夜の決闘

Information

昨日、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に比べると生産性はずっといいんだけど。