コードオーナーシップ

私が遭遇したさまざまなコードオーナーシップのスキームがあります。それらを 3 つの広いカテゴリに分類しました。

• 強力なコードオーナーシップは、コードベースをモジュール（クラス、関数、ファイル）に分割し、各モジュールを 1 人の開発者に割り当てます。開発者は、所有するモジュールのみを変更できます。他の人のモジュールに変更を加える必要がある場合は、モジュール所有者に話しかけて変更を加えてもらう必要があります。他のモジュールのパッチを作成してモジュール所有者に送信することで、このプロセスを加速できます。
• 弱いコードオーナーシップは、モジュールが所有者に割り当てられるという点では似ていますが、開発者が他の人が所有するモジュールを変更できるという点では異なります。モジュール所有者は、所有するモジュールに対する責任を負い、他の人によって行われた変更に目を光らせる必要があります。他の人のモジュールに大幅な変更を加える場合は、最初にモジュール所有者と相談するのが礼儀です。
• 集合コード所有権は、モジュールに対する個人の所有という考え方を放棄しています。コードベースはチーム全体が所有し、誰でもどこでも変更を加えることができます。これはコード所有権がないと考えることができますが、その支持者は、個人の所有という概念ではなく、チームによる所有という概念を強調することを好みます。（集合コード所有権という用語は エクストリーム・プログラミング に由来していますが、第 2 版ではこのプラクティスは共有コードと呼ばれています。）

3 つのうち、私が本当に気に入らないのは強力なコードオーナーシップです。他の人がコードを変更する必要があるような状況は多すぎます。変更を説得し、変更を待つには多くの場合時間がかかりすぎるため、遅延や深刻な問題が発生します。特に変更が簡単な場合に腹立たしいです。

問題を引き起こす簡単な変更の良い例は、公開メソッドの名前変更です。最新のリファクタリングツールは、広く使用されている公開メソッドでこれを行うことができます。ただし、モジュール境界を越えるとコード所有権に違反します。本質的に、開発者間のすべてのインターフェイスが 公開されたインターフェイス に変わり、変更には常にオーバーヘッドが発生します。

さらに悪いのは、実装を変更したい場合ですが、すぐに取得できないため、外部コードのコピーをモジュールに作成し、コードのコピーを呼び出して変更を行う場合です。もちろん、後で問題を解決するつもりです。

弱いコードオーナーシップは、このような種類の問題を軽減する良い方法です。人々は自由に変更を加えることができます。コード所有者は物事に目を光らせておく必要があります。

弱くするかの集団所有権を選択することは、チームの社会的ダイナミクスに関連しています。どちらも同じように成功し、失敗するようです。個人的には、 колекコード所有権チームのダイナミクスの方が好きです。特に、エクストリーム・プログラミングのコンテキストで。