Index: [Article Count Order] [Thread]

Date:  Mon, 8 May 2000 22:22:49 +0900
From:  Kaoru Hosokawa <khosokawa@....com>
Subject:  [XP-jp:00328] XP Chapter 16 Development Strategy 	の解説
To:  extremeprogramming-jp@....jp (extremeprogramming-jp ML)
Message-Id:  <B53CDA40.13FD%khosokawa@....com>
Posted:  Mon, 08 May 2000 22:22:33 +0900
X-Mail-Count: 00328

ホソカワです。

解説の間にコメントがあります。

----

Chapter 16 Development Strategy (開発戦略)
==========================================

連続的なインテグレーション(Continuous Integration)
---------------------------------------------------

長い間インテグレーションを行わないと、システムの整合性の問題が開発行程の終わ
りに発見されたりする。XPでは、単体テストをパスしたコードは、すぐインテグレー
トします。

コードを書いている時は、他のコードに及ぼす影響を気にすることなく、プログラミ
ングします。コードが完成すると、すぐそのコードをインテグレートします。インテ
グレーションでは、ツールがクラスやメソッドの食い違いを検出し、テストが整合性
をチェックしてくれます。このスタイルのインテグレーションは、2、3時間程度で
完了しなくてはなりませんが、refactoring でコードが小さいオブジェクトと小さい
メソッドに分解されているので、コードがかちあう可能性が低いので問題になりませ
ん。

また、連続的なインテグレーションは、開発に「Learn/test/code/release」という、
自然なリズムを与えてくれます。たくさんのタスクで頭が一杯にならないように、一
つ一つタスクを完成するように導いてくれます。

[コメント:
インテグレーションの方法ですが、C++ の環境を考えると、.h と .cpp ファイルに
分けてコードを書きます。開発中は、これらのファイルをチェックアウトするので、
他のメンバーがこれらのファイルを書き変える事はできません。よって、メソッドが
かちあう可能性などありません。複数チェックアウトを許している環境なのでしょう
か?

また、通常、.cpp ファイルにメソッドの定義がまとめて書きますが、1.cpp ファイ
ル1メソッドのように細かくファイルを分割して開発を行ったほうがいいのでしょう
か?
]


共同所有(Collective Ownership)
-------------------------------

XPでは、コードの個人所有などありません。メンバーは、自分で書いていないコード
でも、refactor します。これは、テストとテストの質によって成り立っています。
refactor した他人のコードをすぐテストすれば、その書き直しが正しいかどうかわ
かります。

共同所有によって複雑なコードは排除されます。また、もともと、複雑なコードはか
きません。書いていたとしても、「この後、他のメンバーがすぐにそのコードを
refactor する」と思うと最初から複雑なコードを書きません。

変なコードを発見した場合、すぐに自分で直せるので、他人のコードで自分のプログ
ラミングが中断する事もありません。システム全体の知識もメンバー全員に行き渡る
傾向にもありますので、一人のプログラマーがシステムの善しあしを左右することな
どありません。

[コメント:
だれでも得意、不得意があると思います。メンバーで GUI が得意な人もいれば、そ
うでない人もいます。このようなチーム構成では、やはり、システム全体を全員で開
発する事は難しいと思います。自然と GUI チームと internal チームができそうで
す。このような事態はどのように解決するのでしょう?GUI と internal を両方でき
る人たちを集めるのでしょうか?
]

ペアプログラミング(Pair Programming)
-------------------------------------

ペアプログラミングは、二人のプログラマーたちが会話を通して、コードを書く事で
す。一人がコーディングして、もう一人がそれを見ていると言う事ではありません。
また、個別指導をすることでもありません。新人と組むと最初は、経験が浅いため指
導を受ける場合が多いですが、時間がたつにつれて、新人も同等レベルのパートナー
になります。

二人の馬が合わない場合は、メンバーをシャッフルしましょう。ペアプログラミング
を拒否する人は、他のプロジェクトを勧めましょう。ペアプログラミングの、好き嫌
いもあります。

ペアプログラミングによって情報共有(communication)が円滑になります。一人の
知識がチーム全体に浸透して行きます。Kent 氏の経験によれば、ペアプログラミン
グの方が二人のプログラマーに別々の作業をあたえて、後でインテグレーションする
より生産性が高いそうです。生産性が高くないとしても、片方がコーディングしてい
る間、もう一人が長期的視野を持って考える事によってコードの完成度が高くなりま
す。

また、二人で作業する事によって、プレッシャーから来る、手抜きなどがなくなりま
す。パートナーが必ず見ているからです。二人で間違いを起こす可能性もありますが、
一人で起きる可能性よりはるかに小さいです。

-- 
Kaoru Hosokawa
khosokawa@....com