Index: [Article Count Order] [Thread]

Date:  Wed, 12 Apr 2000 07:38:35 +0900
From:  Kaoru Hosokawa <khosokawa@....com>
Subject:  [XP-jp:00184] Re: XP Chapter7 Four Values 	の解説
To:  extremeprogramming-jp@....jp (extremeprogramming-jp ML)
Message-Id:  <B519647C.D80%khosokawa@....com>
In-Reply-To:  <38F1DEF8.856D68AE@....jp>
Posted:  Wed, 12 Apr 2000 07:37:47 +0900
X-Mail-Count: 00184

ホソカワです。コメントします。

on 2000/04/10 10:55 PM, firo@....jp at firo@....jp wrote:

> 矢崎です。Section1のChapter7 Four Valuesの解説です。
> 
> Section 1 The Problem
> Chapter 7 Four Values
> ===========================================
> 

(略)

> [Courage]
> 第4のValueはCourage(勇気)である。
> 
> Courageとは例えば次のようなことである。
> 
>  1.途中まで問題なく進んでいたプロジェクトが、あるところから、
> ファンクショナル・テストが通らなくなった。その原因は、アー
> キテクチャに欠陥があるせいだとわかった。この場合の正しい
> 対処方法は、アーキテクチャの欠陥を修正せずに、だましだまし
> やることではなくて、アーキテクチャを思い切って修正することで
> ある(例えそのために余分な時間がかかっても)。
> 
> 2.1日の終わりになっても、その日に書いてきたコードが正しく動
>    かなかった場合には、それを捨てて、次の日に、ゼロから始め
> る。
> 
>  3.1つの問題を解決するのに、複数の設計案がある場合、各設
> 計案につき、1日で書ける範囲のコードを書き、それらがどん
> なものかを評価し、そして一番いい案を選択して、あらためて
> 正式なコードを書く(ゼロから)。
> 
> システムが複雑になりすぎた場合には、思いきった手をうつCourage
> (勇気)が必要な場合もある。
> 

ゼロから書き直したいですよね。ただ、3ヶ月経ってから「書き直します。」といっ
たら、だれも聞いてくれませんよね。short release があるからこそできることです
ね。XPの一部だけを実行しても、うまく行かない例のひとつでしょうか?それじゃ、
XPがうまくいく最小限の practices はどんなのでしょうか?

> 上記4つのValueは、相互にサポートしあうものである。例えば、より
> 密にコミュニケーションを行えば、今何が必要で何が必要でないかが
> より明らかになり、システムをよりSimpleに保てるようになる。
> 
> [The Values in Practice]
> 最後に、、4つのValueの下にあって、それらを支えるValueがある。
> それはRespect、つまりチームメンバが互いに尊敬しあうことである。
> 
> 
> ===========================================
> <矢崎のコメント>
> 
> SimplicityとはXPの重要概念の1つだと思いますが、私は以下のよう
> に解釈しています(あくまでも私の独善的解釈です。ご意見お待ちし
> ております)。
> 
> 1.XPのSimplicityとは、今必要な機能だけを作り込む。しかもできる
> だけ単純な構造で、ということである。
> 
> 2.将来的なニーズは、それが本当に必要になった時に作り込む。こ
> れは、これは結局使われない無駄な投資を防ぐ意味がある。また、
> Simplicityの観点からは次のような効果がある。
> 
> (1)システムは機能が増えれば増えるだけ、必然的に複雑になる。
> しかし、最初から100の機能を作り込むよりも、10からスタート
> して、10ずつ機能を作りこんでいくほうが、人間の理解が容易
> になる。

顧客にシステムを見せる立場から、書いています。

この「シンプル」も難しいもので、大きなシステムを作っている場合、何かが動き始
めるまで(目で確かめられるまで)には、何ヶ月もかかってしまうことがあると思い
ます。シンプルかつ顧客にデモできるものを作ろうと言うことですね。

> (2)テストを作成する場合でも、100の機能のテストを作るより、10
> の機能のテストを作り積み上げていくほうが簡単である。
> 
> 3.テストを開発に先立って考えることはシステムをSimpleにする鍵で
> ある。それは、システムを作る基準が、テストを通すための最も
> Simpleなシステムを作るという点に考えを合わせていけるから。
> 
> 4.機能を追加していけば、その都度少しずつシステムは複雑になる。
> しかし、Refactoringは、これを緩和する、あるいは複雑さをゆりもど
> す1つの方法である。
> 
> 後、このChapterでは、Communicationにおけるペア・プログラミング
> というプラクティスが好きです。また、Feedbackを短いサイクルで行う
> べし、それもテストという手段を使ってという点も、注目すべきところと
> 思います。

-- 
Kaoru Hosokawa
khosokawa@....com