2010/10/17
ソフトウェアの肥大化
いやそのりくつはおかしい。というか話が混ざってるような気がする。
高林さんは「ソフトウェアがより広く使われてより多くの機能をサポートするならば、ソフトウェアは肥大化する」という現状についての観察から、ソフトウェアの肥大化は必ずしも悪くないとする。確かにこの命題が真なら、ソフトウェアの肥大化を抑えることは少ない機能で満足せざるを得ないということを意味するから、肥大化を否定するのはよくないだろうということになる。
でもその命題は経験的に導かれたもので、確かに「今の」ソフトウェア開発ではそうなっているけれど、ソフトウェアに内在する不可避な性質として備わっているものかどうかはまだわからないんじゃないかな。
機能PをサポートするコードC(P)を新たに足して、機能QをサポートするコードC(Q)を新たに足して、ってやってふと気づいたら、あるモジュールの切り方を変えるとC(P)もC(Q)も共通機能Xに与える指示をちょっと変えるだけで実現できて、それどころか既存のAやBをサポートするコードC(A)やC(B)も同様にX+αで実現できることがわかった、なんて場合は、機能を増やしたのに全体のコードが減る可能性もある。
いやそうは言ってもね、現場では「万能共通モジュール」＋カスタマイズ、っていうのは必ずしも使い勝手が良くないんだよな、共通モジュールにバグがあると影響範囲が広がるし、共通モジュールを介さずに直接下のレイヤを叩いた方が簡単に書けて、独立してるからメンテも楽だし…なんてぼやきが聞こえてきそうだけど、それは現在そうであるって話だ。未来でも同じように開発していなくちゃならないとは限らない。
上の「共通モジュール」の話でライブラリを思い浮かべた人は多いと思うけれど、もうちょっと一般的な話で、例えばプログラミング言語の設計だって上の議論での最適なXを求める試みだ。そして実際、現在のライブラリという手法は、これからもっと複雑化するソフトウェアにおいて少々力不足かもしれない。既に、膨大なライブラリから欲しい機能を探し出すよりはその場で書いてしまった方が早い、なんてことは起きてるわけで。だから、単にライブラリを整備すれば良いとか、スーパーハイレベル言語を作ればいいとか、そういう単純な話ではない。ソフトウェア開発という行為自体がどう変わってゆくべきかって話になるんだろうと思う。
もちろん、求められる機能がはるかに増えているのに最終的なバイナリのサイズが8bit時代のまま、ということはあり得ない。機能が増えれば、それをサポートするために何かが増えている。プロセッサだって、8bit時代と今とじゃ比べ物にならないくらい内部は複雑になっている。けれどもその複雑さの大部分は、プロセッサのISAやコンパイラのレイヤで吸収されて、アプリケーションプログラマがほぼ気にしなくても良いようにはなってるよね。(もちろん、キャッシュの振る舞いとかメモリの同期とか、アプリケーションコードレベルまで下層の複雑さが顔を覗かせることはあるけれど。でも例えばメモリの同期については新しい言語ではよりはっきり定義されていたりと、徐々にそういうものが中間レイヤでうまく吸収されるようになってきてもいる)。
一般的な人間の頭の中で扱える複雑さってのはたぶん急速には増えないだろうから、人間が扱えるモデルの大きさというのには限界がある。ってことはただソフトウェアが肥大化するに任せてたら人間が扱える範囲を越えるあたりで頭打ちになって、冒頭の命題に照らせば、サポートできる機能に上限があるってことになっちゃう。それは困るから、「ソフトウェア」というのをひとつの混沌とした世界として扱うんじゃなくて整理して、個々の世界は人間の頭の中に収まる範囲にしましょう、ってのがアラン・ケイのやってることなんじゃないかなあ。
もちろん、それと、「今、ここにあるソフトウェアを、現在の顧客の要求に対してどう改良してゆくべきか」っていうのとは違う話で、冒頭のエントリ内で上げられてるJoel Spolskyはそっちの話をしているんだと思う。
Tag: Programming
Post a comment