濱井です。
2001/09/17 16:07:25 +0900にono@....jpさんが送られた
メールに関する返信です。
>>> >リファクタリングを実行したことで、数値として生産性が向上しない限り
>>> >それを業務に適用するのは難しい。
>>> >しかしリファクタリング自体は長期の生産性を支持するものだから
>>> >目前の生産性向上には向かない。
>>>
>>> ソフトウェアの規模を生産量ではなく投入コストと考え、
>>> ソフトウェアを資産ではなく負債（借金）と考えればかなり
>>> 真実に近くなります。
>>>
>>> 「金持ち父さん、貧乏父さん」の本の中で、「家を買うと皆、
>>> 資産と思い込むが、ローンなどでお金を払わないといけないものは
>>> 負債、お金を生み出すものは資産と考えるべき」みたいな話が
>>> ありましたが、ちょっと似てる所がありますね。
>
> > 「価値の下がる資産は、負債と考えるべき」という方が良いでしょう。
> > ソフトウェアは劣化はしませんが、Y2Kなどの例でもわかるように
> > 環境の変化により変更の必要が生じてきて価値が低下します。
> > 価値が下がる資産であるソフトウェアは、必要最小限に抑えておく
> > べきです。
>
>濱井さんのこの議論は、リファクタリングと関係なく「最初に」コードを
>書くときに、そのコード量を小さくしておくべきだ ＝ 投下コストを小さ
>くしておくべきだ、という議論のサポートにはなりますが、追加コストを
>投入してまでリファクタリングでコード量を減らすべきだ、という議論に
>はならないと思いますが、いかがですか？
たしかになりませんね。ロジックがまるまる抜けていました、
すみません。
リファクタリングにより将来の変更コストを減らすことは、価値の低下
を抑制することを意味します。
価値 ＝ 変更をしないですむ場合の価値 − 変更コスト
と考えられます。したがって、変更コストの増大をふせぐ
リファクタリングは、価値の低下を防ぐことになります。
もちろん、価値が低下しなくなるわけではありませんが、
低下のペースを鈍らせることになります。
>ソフトウェアの「資産価値」とはなにかといえば、「将来にわたってその
>コードを稼働したときに生み出される価値を、現在価値換算で表したもの」
>です。それがネットで増える方向にあれば、リファクタリングでコード量
>を減らしても、機能拡張をおこなってコード量を増やしても、どちらでも
>問題ないはずです。
変更コストを差し引いた価値が同じになるならそうでしょう。
ただ、リファクタリングを行わずに機能拡張を行うと将来の変更コスト
が増大して急激な価値の低下を引き起こすため、よほど重要な機能拡張
でないと成り立ちにくいと思います。
>「価値の下がる資産は、負債と考えるべき」なのではなく、「資産価値の
>保全を考える時には、いままでの投下コストを考えてはいけない」という、
>いわゆる「サンク・コストの誤謬」の議論が、この問題に関連するのでは
>ないかと私は考えています。コードの規模が大きいと、その分を回収しな
>くては損してしまうという考えが、リファクタリングに抵抗する人の心理
>にあるのではないでしょうか。
リファクタリングに抵抗する人の心理に「サンク・コストの誤謬」が
ないとは言いませんが、逆に、変更コストが大きくなり過ぎて、その
ソフトウェアを放棄しなければならなくなることを考えると
リファクタリングすべきという論理も成り立ちます。コードを無駄に
しないためリファクタリングするという考えでもいいはずです。