長谷川＠テクノポートです。
----- Original Message -----
送信者 : "Y.Terada" <yterada@....jp>
送信日時 : 2001年 2月 18日 日曜日 午前 01:21
> こんにちは，寺田＠東工大 といいます．
> よろしくお願いします．
面白そうな問いかけですね。
これに続く一連のメールにも目を通しましたが、
どうも私の考え方とは少し違うような気がしたもので、
ちょっと述べてみようと思います。
私自身は、XPをしません。
XPをせずにXPについて考えることが好きです。
そういう者の意見として聞いてください。
> 勉強不足のため理解が不十分なのですが，XP でいわゆるソフトウェアの「再利用」は可
> 能なのでしょうか？
>
> 私は，オブジェクト指向の利点は「再利用」にあると書かれているものを数多く目にした
> ことがありますし，またそのように実感しています．しかし，XP からは「再利用」の「
> におい」が感じられない気がします．
そうですね。私にも、XPが再利用を目指しているとは思えません。
それは単にそう考えることもできるというのではなく、再利用を
ターゲットとしているかどうかにかかっていると思います。
もし、XPが再利用を目標にしているとしたら、おそらく他のどのような
方法論もそういえることになりそうです。
ただ私達の考えている「再利用」が果たしてそれほど有効なものか
どうかは、全く別のことです。他の方も言われていましたが、
再利用とはどういうことなのかを考える必要があると思います。
多くの人が考えている再利用の中にコードの再利用があります。
しかし、パターンでもそういう再利用を目指していません。
デザインパターンは比較的ポピュラーなので読まれたことがあるかも
知れませんが、これとて単純に再利用と言ってしまうと誤解が生じます。
再利用可能なものを作るというようりも、adaptorが典型ですが、
既にあるものを変更せずに使うという、再利用部品ではなく、
再利用技術になっていると思います。これは、通常言われている
再利用とは少し違うと思います。
パターンランゲージに至っては、その再利用性はもっと
違ったものになります。これは言語を構築することなのですが、
言語は私達の考えている再利用性と違うような気がします。
言語はむしろ多様な表現を楽しむことを許します。
これは、いつもいつもおしゃべりをしていて、それでいて
その状況により微妙に変化するものです。
私は、パターンランゲージなるものがもっと多く出てくれば、
もっともっと人はコードを書く、それも良く似たコードを
書くように思っています。それでいて苦にならないと。
そこでの違いは、状況に対する適合性によると考えています。
> YAGNI の原則，というのでしょうか？
> 「いずれ必要になる」と思って余計なコードを書き足すな，という意味ですよね．
> でも，これは再利用を前提として開発する場合には絶対に必要だと思うのです．それを頭
> ごなしに禁止してしまう XP には何となく違和感みたいなものを覚えてしまいます．
ここで「再利用を前提として開発する場合には絶対に必要」と
言われていますね。既にあるものを利用する技術と考えた場合には、
また様相が違ってくるのではないでしょうか。
YAGNIの原則は、ある程度の経験者には「そうだよな」って
感じさせる何かがあります。しかし、これを表現することには
危険がつくまとうと思います。XPがなぜそのようなことを
至極大切なように言うのかを知ることがよいかと思います。
おそらく「明日できるものは今日するな」とは言わないはずです。
そういったことではなく、この洞察は私達当事者の性向、傾向と
いったものと関連していると思います。つまり、あまりに密着し、
細かく見ていくと、必要以上のことをしてしまう傾向が多いと。
少し一般化したレベルで考えると、いわゆるオーバースペックと
いうものがあります。これには幾つかの意味があるようですが、
要求に対して仕様が大きすぎる、また仕様に対して実装が大き過ぎる
という不適合を表していると考えていいかと思います。
これは本来のあり方を崩す大きな原因となっています。
使いもしない仕様を考え、使いもしない機能を実装することに
何の意味があるでしょうか？これは病理的傾向のような気がします。
もっと本当に必要なものの集中すればずっといいものができそうです。
＃ところが、これが案外難しい...(^^。
と、まあ、私はそのように考えるようにしました。
> でも「パターン」という形での再利用は推奨しているのですよね？
> ひょっとして，OO界（？）では，融通の利かなくて思うように再利用できない C++ の言
> 語仕様に嫌気がさして，ソースレベルでの再利用は諦めてしまったのでしょうか（笑）
同じ再利用という観点からアプローチすれば、C++言語だけでなく、
どのような言語を使おうと、同じことが発生します。
ソースレベルの再利用などあきらめた方が私はいいと考えています。
この背景にあるのは、要求に開発が追いつかない状況ですが、
そんなことをしても、焼け石に水と思います。
＃それに、多分面白くなくなるでしょう。
プログラミングの何が面白いかと言うと、何気ないものですら、
それぞれが微妙に適合して、その利用環境にぴったりとはまった時です。
それには、どうしても形を変える必要があります。
ちょっとした工夫が面白いのは、そういうところにあると思います。
パターンにおける再利用性も、今後よく考える必要があると思います。
> XP は，一つのプロジェクト単体の 成功/失敗 に焦点を当てているように思います．しか
> し，会社ではプロジェクトが単発の打ち上げ花火で終わってしまってはダメで，今後につ
> ながるようなノウハウや資源などを蓄積していかなくてはならないのだと思います．その
> ためには，プロジェクトごとに少しでも再利用可能な部分を残せた方が良いはずです．
そういう意識はいいと思います。
しかし、実情を見るととてもそういうふうには見えません。
まず、とにかく助けて欲しいとわらをもつかむプロジェクトが
多すぎます。そこで、他のプロジェクトが再利用可能なものを
提供してくれたら...となります。
これは、現場でちょっと聞けば確認できます。
まず、自分達で作ろうという気がほとんどありません。
それは用意されるものと考えられています。
また、逆に再利用部品を提供する側を考えても、利用者のことを
考えているというよりも、自分達の考えを単に押し付けているだけ
に見えることが多いです。これも確認可能です。
提供したものが、利用される場でうまく適合するかを追跡
調査する人など皆無の状態です。
こういう状況では、神頼みか蜃気楼という程度のものです。
そして、XPにはそういう状況を打開してくれるかもしれない
という期待を個人的には持っています。
> 私の感想としては，XP は単発の戦い（プロジェクト）に勝利するための「戦術」として
> は非常に優れていると思います．しかし，国家100年の計で隣国としのぎを削る「戦略」
> としては，「再利用」という観点が欠けてしまっているような印象を受けます．
国家レベルになると、再利用も優先順位が低くなるような気がします。
もっともっと多くのことが関与し、それこそプロセスやチームワークが
重要になってきます。また、混合状態で共通語を探ることは困難で、
比較的小さなまとまりで、うまく機能させる必要があるとおもいます。
それと、少し気になるのが、もしかしたら統一化のようなことを
考えられているのか、です。または、数少ない優秀な、もしくは
再利用可能な部品を使って、構築すると言ったような。
やかんひとつとっても、大きいもの、小さいもの、材質の違うもの、
形の違うもの様々です。昔は石鹸がオールマイティの時代がありましたが、
今では、ハンドソープ、ボディソープ、シャンプ、キッチン洗剤、バスXXX
など数え上げるのが困難なほどです。これらをひとつのもので済ます
ことはもうできないでしょう。
これらはより文脈に適合するために細分化されたわけですが、
おそらくソフトウェアでも同じ状況が生まれてくると思います。
ソフトウェアに関わっているものにとっては、大変なことですが、
といって単一化、統一化という手段で適応していけるとは思えません。
＃面白い例は、漢字変換ソフトやフォントと言ったものが、
＃淘汰されたと思っていても、携帯電話の中で生きていることでしょうか。
しかし、考え方や構築の仕方といったものは、ある程度単純化する
ことができます。但し、そこにはそういった多様なものを生み出す
可能性を持ったものでないと意味はないと思います。
＃全く同じものしか生産されない仕組みはどのみち壁にぶつかると。
> XP に詳しい方や，すでに XP で開発をなさっている方は，「再利用」に関してはどのよ
> うに対処するつもりなのでしょうか？ もし差し支えなければ教えてください．
これに関しては、何もいえません(^^;。
> 別に，XP に喧嘩を売っているわけではないので誤解なきようお願いします．
> 興味があるからこそ，疑問に思った点をクリアにしたいと思っているだけです．
こういう難しいさがありますね。
私は、XPで再利用など言う必要がないと割切ったほうが、
すっきりすると考えています。それにしたとしても大した貢献が
できるとは思えません。他の方も言われていたように、
そうではなく、再利用を考えるいい状況だと思います。
おかしなフォースに振り回されずに、本当に重要なことに絞り、
健全な成長をしてほしいと、私は考えています。
> 単体テストとリファクタリングの繰り返しで「解」に漸近しようという思想はとっても面
> 白いと思ってます．「解の公式」で根を求めるのではなく，Newton 法で収束計算して根
> を求めようというのと似てますよね．ソフトウェアの設計に「解の公式」が見つからない
> 以上，収束計算で解を求めるしかないですもんね．
>
> ＃ といいつつ，まだやったことはない・・・
接近戦略のひとつかも知れませんが、実際はこれがよく
行われていると思います。私の場合は、もう少しランダムな
動きを付け加えます。自分では、多分ジャンプするための
一手段だと考えていますが。
-- 長谷川(hasegawa@....jp)