続生産性の幻想 -生産性って言葉は適切じゃない-
山本さん(id:iad_otomamay)さんコメントありがとうございます＾＾
続きの意見をつらつら書きます。
ただ元記事で使われている生産性という単語は
「めんどくさくなさ」（ ! めんどくささ ）という意味だと思う。
フレームワークの生産性という場合、
「同じことをするのに、どれだけめんどくさいか？」
という点を評価して、そのFWの生産性と呼ぶのが一般的に使われている語感と最も近いと感じる。
Seaserが生産性の向上を目指しているのは、紛れもないことと思う。
それはFWの設計思想として、優先順位の最上位に何をもってきているかということであって、
Springは「めんどくさくなさ」よりも、包括的であることを選んでいると思う。
上記で、「めんどくさくなさ」がフレームワークの生産性の評価の指標だというように言ったけど、
もうちょっと突っ込むと「フローへの入りやすさ」という表現の方がいいかもしれない。
フロー（Flow）とは、簡単に言えば熱中状態だ。http://ja.wikipedia.org/wiki/%E3%83%95%E3%83%AD%E3%83%BC
エンジニアの生産性のピークは、フロー状態（ゾーンにいるとき）だ。
http://d.hatena.ne.jp/iad_otomamay/20080622/p1
だからこそ、私は「フローを積極的に誘発するフレームワークほど生産性が高い」と考えている。
その「めんどくさくなさ」というのに生産性という言葉をあてはめること自体が無理がある気がする。
それならばもっと適切な単語があるんじゃないかな、と思いつつ見当たらない。だれかーｗ
Seasar流なら「さくさく感」とかになるんだろうか？うーん、個人的にはなんか違う。
ただコンテキストスイッチが少ないフレームワークが良いという意見には賛成。
設定より規約のところはあんま賛同できないけど。SeasarのNamingConventionはちょっといかつすぎるですよ。
それとフレームワークがもたらす最大の利点は生産性じゃなくて、保守性にあると考えてます。
もういまどきのフレームワーク（昔からかも）は開発時だけでなく保守のときにもわかりやすくないと駄目だと思うのが自分の意見。
システムのライフサイクルを考えると、当然技術の流行よりも長いんだから。そこは惑わされちゃいけないと思う。
（作り捨てっていうアプローチならいいけどね）
日本のシステム開発の7割は追加案件（保守案件含む）と言われている中で、そこをもっとクローズアップしてもいいんじゃないかと思う。
保守のしやすさを考えたときにどういうアプローチが最も有効かと考えると、規約ベースは適切な選択じゃない。
規約ベースは規約が5個を超えるあたりから、正直覚えるのもつらい。あとはしかけが見えにくいのも適切じゃないと思う。
また、規約のバッティング等の問題もあるので、本当に慎重に慎重に設計してあげないと実は難しいのが規約ベースのアプローチだと思う。
だからといってコンテキストスイッチが発生するような設定（例えばXML）が適切だと言っているわけじゃない。それはそれで非効率。
今の段階であれば、アノテーションが一番適切な選択でしょう。コンテキストスイッチが発生しにくく、かつIDEの恩恵も受けれるので
うろ覚えでもそれなりにIDE様が適切っぽい候補が出てきます。IDE様マンセーないまどきJava開発だから許されることだけど。
アノテーションによる設定で、例えばDIでいえば、勝手にDIされるよりは@InjectってつけてDIされる方が望ましい。
出来ればどこからってのも書くのが望ましいと思う。
そこに足跡が残るから。ある意味アノテーションは保守する人へのメッセージとも言えるんじゃないかな。
保守のことも考えたフレームワーク開発、これが自分が今挑んでいるテーマです。
まだ答えは見えてこないけど、頑張ってます。
