Index: [Article Count Order] [Thread]

Date:  Thu, 30 Mar 2000 10:06:55 +0900
From:  Yutaka Kamite <y-kamite@....jp>
Subject:  [XP-jp:00066] Re: Section1 Chapter 5 Cost of Change  の解説
To:  extremeprogramming-jp@....jp (extremeprogramming-jp ML)
Message-Id:  <4.0.2-J.20000330095159.00ea5da0@....jp>
In-Reply-To:  <38E023F2.C8816845@....jp>
Posted:  Thu, 30 Mar 2000 10:09:14 +0900
X-Mail-Count: 00066

こんにちは、上手です
ちょっと、コメントさせて下さい。

At 12:09 00/03/28 +0900, you wrote:
> 矢崎です。Section1のChapter5 Cost of Chageの解説です。
> 
> Section  1 The Problem
> Chapter 5 Cost of Change
> ===========================================
> 
> ソフトウエア・エンジニアリングの広く行き渡っている仮定の1つに、
> プログラムの変更コストは、時間が経つにつれて指数的に増加する、
> というものがある。要件定義や分析時に発見すれば解決するのに1
> ドルしかかからない問題でも、製品になった後で解決しようとすれば、
> 数千ドルかかるという具合だ。
> 
> しかし、この仮定はもはや正しくない。テクノロジーとプログラミング・
> プラクティスのコンビネーションにより、時間が経っても変更コストが
> 指数的に増加するとは言えない状況を経験できるようになった。
> 
> K.Beck氏が実際に経験したように、今では非常に短時間に問題を解
> 決することができる(K.Beck氏が経験したのは、稼働中の生命保険
> の契約管理システムで、問題の発見から解決までを30分ほどで行っ
> たものである)。
> 
> ソフトウエア開発のコミュニティは、変更コストを減少させるために、
> 莫大な資源を費やし、よりよい言語、よりよいDB技術、よりよいプロ
> グラミング・プラクティス、よりよい環境やツール、新しい表記法を
> 生み出してきた。こうした投資が実を結び、変更コストが指数的に増
> 加するのではなく、もっとゆっくりと上昇するカーブを描き、最後に
> は漸近線を描くようになったらどうなるだろう。これが、XPの前提の
> 1つである。
> 
> 変更コストが時間が経ってもゆっくりとしか上昇しなければ、コストが
> 指数的に上昇するという仮定のもとで行ってきたやり方とはまったく
> 別のやり方で行うことができる。重要な決定は、できるだけ遅らせる
> ことができる。明日必要になるかもしれないものは、本当にそうなる
> かどうかわからないので、今必要なものだけをインプリメントする。設
> 計に新しいエレメントを追加するのは、そのエレメントが今のコードを
> より単純明快にするか、あるいは次に書くコードが単純明快になると
> きだけである。
> 
> 変更コストを低く押さえるための鍵となる技術がオブジェクト指向で
> ある。メッセージ・センディングが、変更の数多くの機会を安価に作
> り出すための強力な方法である。また、オブジェクト・データベースは、
> この柔軟性を、永続記憶の領域へともたらす。
> 
> 製品化して数年たった後でさえもコードを簡単に修正できたという事
> 例から、以下のような、いくつかの要因を抽出できる。
> 
>  ・単純明快な設計
>    余分なエレメントがない設計。今は必要ないが、将来的に必要
>    になるかもしれないような余分なエレメントは含まない。
> 
>  ・自動化テスト
>    自動化テストを行えば、知らない間にシステムの既存のふるま
>    いを変更してしまったかどうかを見逃すことがない。
> 
>  ・設計を変更するために役立つ数多くのプラクティス
>    システムを変更するときに、心配しすぎることがなくなる。

ここは、
設計変更を沢山やっているので、システムを変更する時が来ても、
それを恐れない
と、読んだのですが。

> 
> 変更コストの増加についての仮定が変化したことで、私達は、ソフト
> ウエア開発に対するまったく別のアプローチをとることができる。こ
> の新しいアプローチは、他のアプローチと同じように規律的である。
> しかし、次元は異なる。旧来のアプローチは、開発の早期に大きな
> 決定を行い、後のほうでは小さな決定だけをすることを良しとする。
> 新しアプローチは、決定をすばやく行い、それをテストで検証する。
> そして、その設計について、よりよい方法を学習した時に、設計を
> 改良していけるように準備しておくのである。
> 
> しかしながら、このようなアプローチを作り上げることは容易ではな
> い。私たちは、よいソフトウエア開発に効果のあるものについての、
> 最も深いところの仮定を再検証しなければならないであろう。まず
> は、私たちが行う他の全てのことをanchor(?)するであろう、1つの物
> 語から始めることとする。
> 
> (矢崎::最後のAnchorって何て訳せばいいでしょう?)
> 

上手訳:(冗談調)
しかし、このようなアプローチを創りあげることは容易ではない。
私たちは、良いソフトトウェア開発をするための最も深い部分の仮定を
再検証しなければならない。
#ここまでは、矢崎さんの引用
旅を始めよう。
まず、いまやっている全てのことを、棚上げにして。

#anchor というのは、文字通り、「錨をおろす」ことのようなので、
・やっていること全てを固定する(中止ではない)
・しっかり動きをとめる
のような訳になると思います。
ここでは、意訳して、「棚上げ」としてみました。

(以上)

> (矢崎::本当はホソカワさんがやるところでしたが、私が無理言って
> やらせてもらいました。)
> 
> --
> 矢崎 博英 <firo@....jp>
>  
-----------------------------------------------
y-kamite@....jp
上手 裕(Yutaka Kamite)
(株)データ通信システム 品質推進部
tel:03-3437-7524  fax:03-3437-7521
-----------------------------------------------