http://martinfowler.com/bliki/CodeOwnership.html

コードの所有には、私が今まで見てきたものだけでも、いくつかの形がある。ここでは大きく3つのカテゴリに分けてみた。

  • 強いコードの所有では、コードはモジュール（クラス、関数、ファイル）などに分かれており、それぞれが一人の開発者に割り当てられている。開発者は自分のモジュールだけを変更することができる。他の開発者のモジュールを変更したい場合は、モジュールの所有者に頼んで変更してもらうことになる。または、パッチを書いて送りつける方法もある。

  • 弱いコードの所有では、上記と同様、モジュールが各開発者に割り当てられているが、他の人のモジュールも変更してもよいという点で異なる。モジュールの所有者は割り当てられたモジュールに責任を持ち、他の人によって変更が加えられることに気を配る必要がある。他の人のモジュールに大幅な変更を加える場合は、きちんとそのモジュール所有者に断りを入れるのがよいだろう。

  • コードの共同所有では、モジュールの割り当てそのものを行わない。コードはチームの所有物であり、誰もがどのコードにも変更を加えることができる。コードの所有という考えがが無いと考えてよい。ただ、コードの共同所有を提唱する者たちは、個人ではなく「チームに」所有されていることを強調している（チームによる共同所有は、エクストリーム・プログラミングからきている。2版では「Shared Code」と呼ばれている。）。

このなかで私が大嫌いなのは、強いコードの所有である。他の人のコードを変更しなければならないことは多々ある。変更を頼んで修正を待っていては時間がかかりすぎてしまい、問題の修正が遅れ、事態は深刻になる。変更がシンプルな場合はなおさらイライラすることになる。

シンプルな変更とは、たとえばpublicメソッドのリネームなどである。現代のリファクタリングツールは、安全にすべてのpublicメソッドを変更することができる。しかしこのメソッドが複数のモジュールにまたがっている場合、コードの所有を違反してしまうことになる。基本的に、開発者間のインタフェースは、変更によるオーバーヘッドも含めて、すべて公布済みインターフェイスに置き換えるべきだ。

さらによくないのは、実装の変更を行う場合だ。すぐには変更できないので、自分のモジュールにその外部コードをコピーし、そのコピーを呼び出しながら変更を行うことになる。もちろん、あとからきちんと整理する必要がある。

弱いコード所有は、上記の問題を軽減してくれる。開発者は自由にコードを変更することができ、コードの所有者はその変更に注意しておきさえすればよい。

弱いコード所有とコードの共同所有との選択は、チームの社会的なダイナミックスさ(the dynamics of the team)に関係してくる。どちらも同様に機能もするし、失敗もするだろう。個人的には（特にエクストリーム・プログラミングを使用した）コードの共同所有ができるダイナミックなチームが好みだ。