上手＠データ通信システム です。
修正完了版です。ちょこちょこ直しました。
残りの３つ、24,25,26についても完了版をpostしますので、
webにあげるのはそれまで待って下さい ＞矢崎さん
XPractices 23.
Code Ownership
コード所有権
我々はコード所有権を使わない。ある機能について複数のクラスが始めて
開発される時は、普通は一つのチームのみが、当初の開発に必要な一つの
イテレーション（繰り返し）の間だけ担当する。
その後は、いつでもどのチームでもクラスを扱う機会があれば、拡張であ
れ修正であれ自由に行う。
我々は頻繁にリリースするので、コードの衝突はほとんどない。我々は
ENVYを拡張し、リリースしたクラスに基づかないクラスのバージョンを発
見したら警告するようにした。警告が出て、我々が始めたものと違うもの
なら、その変更をリリースバージョンに統合する。（もし必要ならば、我
々の直前にリリースしたチームが助けてくれるだろう。）
反論
所有権の欠如は人々に、仕事の責任が小さくなったと感じさせるかもしれ
ない
・全てのグループがすぐに自分たちの仕事を見るのだから、品質について、
より少ないどころか、より多く注意を払うようになる
反論
オーナでない者はクラスを理解せず、壊してしまうかもしれない
・クラスは単体テストを100％通らないといけないので、誰によってなさ
れた変更でも自動的に品質要求に従う。
・クラスを変更しているチームにそのクラスの経験が無くても、ペアプロ
グラミングが、２組の両目が変更を見守ることを確実にする。
・通常、もしクラスが複雑なら、オリジナルな作者の一人が呼ばれて変更
を助ける。
オリジナル http://www.xprogramming.com/
Copyright (c) 1999, REJeffries et al. (ronjeffries@....org)