Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
25 lines (14 sloc) 3.75 KB
title tags
コードの所有
team organization
extreme programming
process theory

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

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

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

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

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

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

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

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

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

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

You can’t perform that action at this time.