矢崎です。相当遅いリプライですが、ごめんなさい。。。
Yutaka Kamiteさん wrote:
> > > Section 1 The Problem
> > > Chapter 5 Cost of Change
> > > ===========================================
> > > ・設計を変更するために役立つ数多くのプラクティス
> > > システムを変更するときに、心配しすぎることがなくなる。
> >
>
（略）
>
> ・設計変更の多くの実行
> システムを変更する時でも、それほどおそれなくなる
>
タイトル部分は、プラクティスが、実行そのものを意味しているのか、
実行する上でのこつ、作戦、策略、方針というような意味なのか、ち
ょい不明ですので、プラクティスそのままにさせてください（今のとこ
ろ）。
＃この点についてどなたか教えていただければ助かります。
本文のほうは上手さんの書かれたもののほうが、日本語として自然な
ので、修正します。
>
> > > しかしながら、このようなアプローチを作り上げることは容易ではな
> > > い。私たちは、よいソフトウエア開発に効果のあるものについての、
> > > 最も深いところの仮定を再検証しなければならないであろう。まず
> > > は、私たちが行う他の全てのことをanchor(?)するであろう、１つの物
> > > 語から始めることとする。
> > >
> > > （矢崎：：最後のAnchorって何て訳せばいいでしょう？）
> > >
>
（略）
>
> 以下に修正致します。矢崎さんの解釈通りです。
>
> しかしながら、そのようなアプローチを創ることは容易ではない。
> 私たちは、よいソフトウェア開発を行うための、最も深い部分の仮定を
> 再検証しなければならないだろう。
> 私たちは、ステージに上がった旅を始めることが出来る。まず、私たちが
> 行う全てのことをしっかり括りつけるであろう一つの話から始めよう。
>
上手さんのご教示にAgreeです。
「私たちは、ステージに上がった旅を始めることが出来る。」の部分を除いて
（なぜなら、この部分がなくても意味は通じると思いますので）修正します。
ということで、以下修正版です。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
矢崎です。Section１のChapter５ Cost of Chageの解説です。
Section 1 The Problem
Chapter 5 Cost of Change
===========================================
ソフトウエア・エンジニアリングの広く行き渡っている仮定の１つに、
プログラムの変更コストは、時間が経つにつれて指数的に増加する、
というものがある。要件定義や分析時に発見すれば解決するのに１
ドルしかかからない問題でも、製品になった後で解決しようとすれば、
数千ドルかかるという具合だ。
しかし、この仮定はもはや正しくない。テクノロジーとプログラミング・
プラクティスのコンビネーションにより、時間が経っても変更コストが
指数的に増加するとは言えない状況を経験できるようになった。
K.Beck氏が実際に経験したように、今では非常に短時間に問題を解
決することができる（K.Beck氏が経験したのは、稼働中の生命保険
の契約管理システムで、問題の発見から解決までを３０分ほどで行っ
たものである）。
ソフトウエア開発のコミュニティは、変更コストを減少させるために、
莫大な資源を費やし、よりよい言語、よりよいDB技術、よりよいプロ
グラミング・プラクティス、よりよい環境やツール、新しい表記法を
生み出してきた。こうした投資が実を結び、変更コストが指数的に増
加するのではなく、もっとゆっくりと上昇するカーブを描き、最後に
は漸近線を描くようになったらどうなるだろう。これが、XPの前提の
1つである。
変更コストが時間が経ってもゆっくりとしか上昇しなければ、コストが
指数的に上昇するという仮定のもとで行ってきたやり方とはまったく
別のやり方で行うことができる。重要な決定は、できるだけ遅らせる
ことができる。明日必要になるかもしれないものは、本当にそうなる
かどうかわからないので、今必要なものだけをインプリメントする。設
計に新しいエレメントを追加するのは、そのエレメントが今のコードを
より単純明快にするか、あるいは次に書くコードが単純明快になると
きだけである。
変更コストを低く押さえるための鍵となる技術がオブジェクト指向で
ある。メッセージ・センディングが、変更の数多くの機会を安価に作
り出すための強力な方法である。また、オブジェクト・データベースは、
この柔軟性を、永続記憶の領域へともたらす。
製品化して数年たった後でさえもコードを簡単に修正できたという事
例から、以下のような、いくつかの要因を抽出できる。
・単純明快な設計
余分なエレメントがない設計。今は必要ないが、将来的に必要
になるかもしれないような余分なエレメントは含まない。
・自動化テスト
自動化テストを行えば、知らない間にシステムの既存のふるま
いを変更してしまったかどうかを見逃すことがない。
・設計を変更するために役立つ数多くのプラクティス
システムを変更する時でも、それほどおそれなくなる。
変更コストの増加についての仮定が変化したことで、私達は、ソフト
ウエア開発に対するまったく別のアプローチをとることができる。こ
の新しいアプローチは、他のアプローチと同じように規律的である。
しかし、次元は異なる。旧来のアプローチは、開発の早期に大きな
決定を行い、後のほうでは小さな決定だけをすることを良しとする。
新しアプローチは、決定をすばやく行い、それをテストで検証する。
そして、その設計について、よりよい方法を学習した時に、設計を
改良していけるように準備しておくのである。
しかしながら、そのようなアプローチを創ることは容易ではない。
私たちは、よいソフトウェア開発を行うための、最も深い部分の仮定
を再検証しなければならないだろう。まず、私たちが行う全てのこと
をしっかり括りつけるであろう一つの話から始めよう。
（矢崎：：本当はホソカワさんがやるところでしたが、私が無理言って
やらせてもらいました。）
--
矢崎博英 firo@....jp