パターン17:コード所有者

   

 

問題:

開発者は、コードの変更を継続してし続けることができない。

コンテキスト:

ソフトウエアアーキテクチャをドキュメント化し構築しようとしている組織で、開発者にコーディングを行わせようとしている時。

影響する事柄:

全員の責任であるということは、誰も責任を持っていないのと同じ。

開発者間での平行作業を行いたい。複数の人が同時にコーディングをすることができる。

ほとんどの設計上の知識はコードの中にある。設計上の課題を調査するためになれないコードを読むのには時間がかかる。

間に合わせの変更はうまく動いたためしがない。

いつもすべてのことをすべての人が知っていることは不可能である。

解決策:

システムの中のそれぞれのモジュールを一人の開発者に所有させるようにする。例外的あるいは明確な状況である場合を除き、コードはその所有者によってのみ修正してよい。

結果として生じるコンテキスト:

アーキテクチャと組織はお互いによくなるように影響しあう。関連するパターンとして、アーキテクチャ設計者もソフトウエア実装に参加する組織は市場にしたがうおよび割り込みは閉塞状況を解除するがある。

このパターンを厳密に適用すると、開発者やアーキテクチャ設計者の視野は狭くなるが、アーキテクチャをレビューしなさいのパターンはそのようになることを避けるのに役に立つ。

論理的根拠:

コード所有者がいないと、今日のような大規模なソフトウエア開発においては、問題がどこにあるのかを発見するのが大変である。コードの所有は、アーキテクチャと連携しており、所有するためには、所有者間のインタフェースがなければならない。これは小規模でのConwayの法則の形式の1つである(アーキテクチャ設計者もソフトウエア実装に参加するのパターンを参照)。

コード所有に対しての反論は多くあるが、経験的な方向はその価値を支持している。典型的な反論として、視野が狭くなるという傾向、あるコードについてある程度深くわかっているのは1人だけであるという言外のリスク、あるいは全体的な知識の細分化などがある。他のパターンはこの問題を緩和する(アーキテクチャをレビューしなさいおよび顧客の参加のパターンを参照)。

Tim Bornは、C++の保護機能がある人が他の人の抽象的概念の実装にアクセスするのを防ぐという意味で、コード所有とカプセル化の間には関連があると主張している。

法律は所有物であり、識別できる所有物がないと無政府状態になる(ルソー他)。

コード所有は再利用可能なコードにのみ適用されるべきであるという議論がなされてきた。もし誰かが役に立つコードと再利用可能なコードの明確な違いを説明できるのなら、そのような制約は価値があるかもしれない。