生産性について - フレームワーク
その「めんどくさくなさ」というのに生産性という言葉をあてはめること自体が無理がある気がする。
2008-06-23
というご意見がありながらも、とりあえずここでは生産性という言葉を使って喋ることにします*1。
「フレームワーク(以下F/W)がもたらす生産性」という言葉に私が違和感を感じるのは、おそらくここで言う生産性って言うのを次の単純な式で計算してるからではないかな、と電車で思いました。
- F/Wが削減したコスト*2 = F/Wが肩代わりしたコスト - F/Wのための記述コスト
このため、次のような単純な方法をつかうと、ここで言う生産性というものが劇的に向上します。
- F/Wが肩代わりできる部分を最大に
- F/Wのための記述コストを最小に
- Convensionで代替する
- zero-configurationでうまく動くようにする
たしかに、上記項目を徹底的に突き詰めれば先ほどの「F/Wが削減したコスト」の計算式においてはかなり多くのコスト削減(誤解を恐れずに言えば、生産性の向上)が望めると思います。
F/Wへの配慮
しかし、こんな意見もあります。
規約ベースは規約が5個を超えるあたりから、正直覚えるのもつらい。あとはしかけが見えにくいのも適切じゃないと思う。
2008-06-23
これは「学習コスト」のようにも一見見えますが、実はそれだけじゃないと思います。ということで、式をアップデート。
- F/Wが削減したコスト= F/Wが肩代わりしたコスト - F/Wのための記述コスト - F/Wへの配慮コスト
意外と語られてないのが「F/Wへの配慮コスト」だと思います。「こう書けばF/W様が慈悲を授けてくれるはず」というおまじないを覚えなければなりません。これは学習コストという1回だけのコストではなく、常に付きまとうコストとなります。
厄介なことは、このコストが仕様策定した人からすると極小のように見えてしまうところです。仕様策定した人と少しでも違った感性を持っているだけで、その仕様への配慮はかなりの苦痛となるはずです。
逆に、万人にとってその記述がアフォーダンスを持つもの(こうすればこうなるという期待を裏切らないもの)であれば、その配慮は微小になるかもしれません。しかし、規約自体を忘れた人からすれば、それは書いた以上の意味を持たないリテラルとして認識されてしまうでしょう。
ともあれ、「F/Wが肩代わりしたコスト」の増大、「F/Wのための記述コスト」の削減はいずれもプロダクトのブラックボックスの向上につながる可能性があります。よほど繊細なアフォーダンスの設計がなされていない限り、F/Wへ配慮するコストは増大していくものと思います。
F/Wの生産性への寄与
一転してF/Wがもたらす生産性への明るい側面について考えてみました。id:iad_otomamayさんによると「めんどくさくなさ」でまさにこれがズバリなのですが、もうちょっと分解してみようと思います。
私がF/Wに求めるものは「作業ドメインの限定」です。F/Wは基本的にある特定ドメインの作業を肩代わりするシステムだと思っていて、DIなんかは「オブジェクト依存グラフ」というドメインをいろいろと考えるまでもなく解決してくれます。また、DIコンテナにはさまざまなコンポーネントが提供されていて、それらを利用するとDBのトランザクション処理に関するドメインを肩代わりしてくれたり、またはきれいにコード上から分割してくれたりします。
ここで、私の経験則からいくつか仮定を立てます。
ここでいう作業ドメインとは大雑把なもので、関連技術やらコードの傾向などが似通ったものが同一のドメインとします。ともあれ、同一のドメインでは「覚えることがある程度限られている」という傾向があります。
少し前に書いたエントリと照らし合わせてみると、
生産性について - しげるメモ
- 最も記述速度が速いのは、「コード書く以外にやることがなくなった」とき
- 「あれなんだっけ？」って考えた瞬間に集中力がいったん途切れる
- 覚えておくべきことを最小にする
というように、「やるべきことを制限する」「自分の得意な箇所をひたすらやる」「覚えておくことを少なくする」ことができるようなF/Wこそが、真に生産性を向上させるものだと考えます。
そういう意味で言うと、コードの記述量削減自体は実は大して生産性に寄与してなくて、やるべきことの種類が減った、自分が得意でない部分が削減された、コードが短くなったことで覚えるべきことが少なくなった、という点で生産性が向上している可能性があります。
それとフレームワークがもたらす最大の利点は生産性じゃなくて、保守性にあると考えてます。
2008-06-23
把握すべきドメインが減った、という意味で生産性よりも保守性が高くなったのかもしれません。
新しいドメイン
F/Wへの配慮と、F/Wがもたらす生産性は、かなりのバランス感覚が重要だと思います。
記述を少なくすることで、「F/Wへの配慮という新しいドメイン」が出現してしまうためです。逆に、配慮を怠ってしまうと呪文を見逃して予想外の動作をしてくれるので、「配慮すべき項目」自体をまず極小にするようなF/Wが好きです。
そういう意味では、現在の流れだとアノテーションが最強な感じでしょうか。
- 自己説明的 (覚えることが少ない)
- 知らない人をびっくりさせられる (配慮を怠ってしまうリスクが低い)
長々と書いてしまいましたが、こんなF/Wがいいなというのを挙げて終わりとしたいと思います。
- 一貫した設計思想
- 例外が多いと無理
- 自己説明的なものにアフォードされていること
- フレームワークへの記述の種類が少ない
- 一貫した設計思想のうえで、数少ない語彙を提供する
ただし、上を守り続けてしまうとF/Wの対象ドメインが狭くなる可能性があるので、結局はトレードオフの部分がありそうです。
あ、ちなみに私はフレームワークを作る仕事ではなく、プログラマをZoneに招くだけの簡単なお仕事に携わっています。求人中のようです。
