濱井です。
2002/06/18 09:48:51 +0900にkataoka646@....comさんが送られた
メールに関する返信です。
>
>> 欠陥が多いとXPのように変更を繰り返す
>> と欠陥が欠陥を生んで収拾がつかなくなるおそれがあります。
>
>それを回避するためのテストでは？
はい。ですから、収拾がつかなくなることを防ぐため、欠陥をある程度
以下に押さえ込んでおけるようにテストするわけです。XPにおけるユニット
テストは、欠陥を虱潰しに捜して積極的に欠陥を減らすようなものでは、
通常ありません。
>欠陥が欠陥を生むのはむしろ
>
>> 信頼性を高めるためには、可能な限りソフトウェアを変更しないように
>> すべきであり
>
>という従来の考え方だと思います。
ソフトウェアを変更しなければ欠陥は増えません（減りもしませんけど）。
従来の考え方は、ソフトウェアを変更しないようにするために、仕様変更や
リファクタリングをせずにすむようなソフトウェアを開発するということ
であって、仕様変更やリファクタリングがさけられないソフトウェアを
開発しておいて仕様変更やリファクタリングをしないということでは
ありません。
しかし、仕様変更やリファクタリングをせずにすむようなソフトウェアの
ソフトウェアの開発は不可能と言ってもいいほど困難ですし、コストも
多大になります。ですから、変更を減らすのではなく、変更によって欠陥を
作り込む確率を減らすという考え方をXPなどは取り入れたのです。
>変更しないことで信頼性を高めるという主張は、変更前のコードの信頼性が十分
>高いことを前提としています。ところがソフトウェア開発においてはある時点で
>の信頼性の高さはあまり意味がありません。顧客の要求により突然仕様が変更さ
>れれば、変更前の仕様を前提とした信頼性の高さは無意味です。
そんなことはありません。欠陥の多い、わかりにくいソフトウェアの仕様を
変更するくらいなら、最初から作り直した方がましとはよく言われることです。
> 従来の考え方で
>は、仕様変更によって意味を失ったコードを無理矢理延命させるために場当たり
>的な修正を加え、その結果として潜在的欠陥が累積されるというパターンが度々
>見られます。
修正も変更の一種です。変更しているのだから欠陥がふえても不思議では
ありません。
片岡さんが批判しているのは、従来の信頼性を重視したソフトウェア開発手法
ではなく、従来の信頼性を＊軽視＊したソフトウェア開発手法のように
見えます。