Index: [Article Count Order] [Thread]

Date:  Thu, 11 May 2000 23:32:19 +0900
From:  Kaoru Hosokawa <khosokawa@....com>
Subject:  [XP-jp:00337] Re: Chapter 2 A Development Episode
To:  extremeprogramming-jp@....jp (extremeprogramming-jp ML)
Message-Id:  <B53F89EF.145D%khosokawa@....com>
In-Reply-To:  <3917E080.1904459A@....jp>
Posted:  Thu, 11 May 2000 23:32:03 +0900
X-Mail-Count: 00337

ホソカワです。

コメントありがとうございます。

on 2000/05/09 6:54 PM, 佃 軍治 at tsukuda@....jp wrote:

> 
> 佃です。
> 
> やっと本が手に入りました。
> 以下の抄訳を担当しようと思います。
> 
> Chapter 23  20-80 Rule (2)
> Chapter 24  What Makes XP Hard (4)
> Chapter 25  When You Shouldn't Try XP (4)
> 
> *** 
> 
> かなり遅いレスポンスですが、2章についてコメントします。
> 
>> 
>> ホソカワです。
>> 
>> Chapter 2 A Development Episode
>> ==============================
>> 
>> この章では、開発エピソードを紹介します。「プログラマーがタスクを実装して、シ
>> ステムに統合する。」と言う話です。
>> 
>> 積み重ねたタスクカードの一番上のカードには、「今四半期源泉課税を公開する。
>> (Export Quarter-to-date Withholding.)」と書いてある。[Export Quarter ... 
>> の訳には全然自信がありません。]君が今朝の立ち会議(stand-up meeting)で、今
>> 四半期計算を終えている事を思い出した。君に助けを求めると「いいよ。」と言う。
>> これで、二人は、ペアプログラミングパートナーになった。
>> 
>> 私達は、君が昨日行った作業について復習した。君が「このタスクのテストケースは
>> どんなの?」と聞いたので、「公開ステーションを実行すると公開レコードの値と入
>> れ物(bins)の中の値が合わなくてはならない。」と答えた。どのフィールドの値を
>> 埋めなくてはならないのかわからず、Eddieに聞くことにした。Eddieは、5つのフィ
>> ー
>> ルドについて教えてくれた。
>> 
>> 私達は、現在のテストケースから使えそうなものを見つけ、スーパークラスを作成し
>> 、
>> refactoringを行い、現在のテストケースを流した。全てテストは通った。さらに、
>> 今作ったスーパークラスが他のテストケースでも使えることに注目し、タスクの結果
>> を見たかったので、to-do カードに「AbstractExportTestを改良」とメモを残した。
>> 
> 
> これって、テストケースのコードをリファクタリングしているんで
> すよね。
> 機能を実装するコードだけでなく、テストケースもリファクタリン
> グするとは思っていませんでした。
> 

やはり、なんでもシンプルにすることがいいのでしょう。テストケースもコードも同
じレベルのものとして扱っているのでしょう。

>> テストケースは、スーパークラスのおかげで、簡単に作ることができた。テストケー
>> スを作っている最中にタスクの実装アイディアが浮かんだのでto-do カードに書き込
>> んだ。テストケースを流したが、タスクの実装をまだしていないので、もちろん通ら
>> ない。[ここで、Ralphと書いたテストケースの話題になりますが、何を言いたいのか
>> よくわかりませんでした。(次の文章に繋がらなかった。)]
>> 
>> デバッガを立ち上げ、関係するオブジェクトを解析し、コーティングをする。コーデ
>> ィ
>> ング中、さらにテストケースが浮かび上がったのでto-do カードに追加した。実装後
>> 、
>> テストが通るようになった。次々とテストケースをこなしていった。
> 
> キーボードを操作していない人(B)が、コードが単純になること
> に気づき、キーボードを操作している人(A)に説明しようとする
> が、Aがめんどくさくなって、キーボートをBに渡す、
> 
> という内容がこの次にありますが、この内容はまとめに入れていた
> 方がいいのではないでしょうか?
> ペアプログラミングは、一人がキーボードを操作し、もう一人は指
> 摘するだけ、という誤解が解けますので。
> 

はい、そうします。ところで「まとめ」とは?

>> その後、to-do
>> カードには、「その他のテストケースの改良」しか残っていなかったので、改良を行
>> い、テストが通ることを確認した。
> 
> 【to-do カードに「AbstractExportTestを改良」とメモを残し
> た。】ことが、ここでのテストケースの改良に繋がっている、とい
> う解釈でいいのでしょうか?
> 
>> 
>> インテグレーション用マシンが空いていたので私達の変更を加えてテストを行ったが
>> 、
>> テストは通らなかったがテストをデバッグし、コードを修正した。今度はテストが通
>> り、私達のコードをリリースした。
>> 
>> XPの開発サイクルで注目すべき点は、
>> 
>> ・二人組でプログラムを書く(pair prgramming)
>> ・テスト主導で開発する。テストを書いてからコードを書く。テストが通り、これ以
>> 上テストを考え付かない時、完了する。
>> ・テストを通すことだけが目的ではなく、システムの設計も進化させていく。
>> ・インテグレーションとインテグレーションテストはコーディング完了後、ただちに
>> 行う。
>> 
> 
> テストケースを考え、コードとして記録してから、実装コードを書
> く、という考えはいいですね。
> 機能のWhatを明確にして(再認識して)から、HOWを行うと
> いうことになるので。
> ちょっと試してみたい、という衝動に駆られます。

そうそう、テストがスペックになっていますね。

-- 
Kaoru Hosokawa
khosokawa@....com