Subscribed unsubscribe Subscribe Subscribe

生産性を高めるために作られたものではないのです。

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

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

Strutsは、Webの世界のMVCを普及させるために生まれたものであり、生産性を高めるために作られたものではないのです。

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

CTCと夜の決闘

これ、似たようなこと前に書いたし、ブクマコメントだと字数が足りないので一言言ってみる。

ひがさんはきっとStrutsの開発者がどのような目的でStrutsを作ったかについてはあまり関心がなく、Strutsが*日本*で普及した結果、どういうことが起こったかという結果論で見ているんだろうな。だから、ただ一読しただけでは上のエントリのコメントのような「WTF?」という心持ちになるわけで。ちなみに、俺だったら、こんなに断定的に書いた後は、きっと自責の念にとらわれるよ。

ただ、「EJBに比べると生産性はずっといいんだけど」「生産性そのものは改善しません」って言い方はいくらなんでもない。意味がわからない。おそらく、ひがさんのいう生産性は2種類あるんだろう。

  1. コーディングにおいて、時間あたりの完成度の上昇率、ベロシティをいかに大きくするかという意味での生産性の向上。(つまり、この視点ではプロジェクトの規模はあまり関係ない。)
  2. 同程度の製品を生み出す過程 (工数) が全体としてどの程度縮まったかという意味での生産性の向上。

ここで前者がひがさんの問題にしたい「生産性」だとして、ちょっと頭をひねってみる。

今のところそういう噂は聞かないけど、仮に Rails は 1. の意味では比較的生産性が高いけど 2. の意味では、他の手法と比較して生産性が低いという話になったとする。一体、この矛盾をどう見るべきなんだろうか。

あと 1. はプログラマ個人の一人称的な視点で、2. はプログラマを三人称的に捉えた視点なんていう言い方もできるかもしれない。
そういう意味で、定型化するというのは、コミュニケーションの齟齬を減らすことにつながるので、2. の視点ではかなり生産性を向上する要素になり得ると思うなあ。

とまあ、なんか言いたいことはあったんだけど疑問形で終了。

まとめ: 文意が分かりづらいけど基本的には同意ってことで。