個々のコードの所有権は重要ですか？[閉まっている]

私は、コードベース全体のチームの所有権が、コンポーネントの個々の所有権よりも優れているかどうかについて、一部の同僚と議論している最中です。

私は、チームのすべてのメンバーにコードベースのほぼ等しいシェアを割り当てることを強く支持しています。これにより、人々は自分の作成に誇りを持ち、バグスクリーナーに着信チケットを割り当てるための明らかな最初の場所を与え、「壊れたウィンドウ症候群」を軽減するのに役立ちます。

また、特定の機能に関する知識を1人（または2人）のチームメンバーに集中させ、バグの修正をはるかに容易にします。

何よりも、委員会ではなく、多くの意見を持っている一人の人との主要な決定について最終決定権を置きます。

他の誰かがあなたのコードを変更したい場合、許可を要求することを支持していません。多分、コードのレビューは常に所有者に委ねてください。また、知識のサイロを構築することもお勧めしません。この所有権について排他的なものはないはずです。

しかし、同僚にこれを提案したとき、私は予想以上に多くのプッシュバックを得ました。

だから私はコミュニティに尋ねます：大規模なコードベースでチームと協力することについてのあなたの意見は何ですか？集団所有権を慎重に維持することに関して私が逃しているものはありますか？

長期的には、チームオーナーシップの方がはるかに有益だと思います。

次の2つのシナリオを見て、最小限の人数で知識を集中することが理想的ではない理由を理解する必要があります。

• チームメンバーが不幸な事故に遭遇
• チームメンバーがより良い雇用機会に出会う

当然、特定のセクションを書く人/人はそれについてより多くの知識を持っていますが、それらを唯一の知識のサイロにする誘惑に屈しません。サイロ は、長期的な苦痛による短期的な勝利をもたらします。

コードのセクションを個別に所有していないからといって、それを書いたからといって、「あなたの創造に誇りを持っている」などの側面がまだないというわけではありません。記述されたコードの所有権に関する個人的な感情を軽減します。

最終的に、チームはコードを所有します。しかし、あなたが言及したすべての理由から、コードの特定の部分に個々の著者を指定しました。各作成者は、コードの各部分に対して主な責任を負い、コードベース全体に対して副次的な責任を負います。

コードベースの一部の問題が表面化した場合、私は元々修正のためにコードを書いた人に戻ろうとします。もちろん、他のチームメンバーが修正を適用するのを妨げるものは何もありません。すべてのチームメンバーは、他のすべてのコードに精通している必要があります。しかし、私たちは常に最初に元の著者から修正を取得しようとします。結局、彼らはコードを書きました。彼らはそれに最も精通しています。

私はチーム環境で働きました。人々は自分が書いたものに所有感を感じなかったため、優れたコードを書くことを強いられず、平均的なコードを書くだけでした。

私は、製品に関する知識を広める理由についてのビジネススタンスから同意します。現実には、個人が何かの特定の領域に努力を集中することは、時間の経過とともに、その特定の領域にはるかに精通するようになります。

これを無視することは、科学を無視することです。残念ながら、脳は遭遇したすべてを保持することができません。与えられた瞬間に有効で価値のあるものを思い出しますが、そのストレージでさえ時間とともに減少します。

より大きなコードベース内の特定のモジュールまたはコンパートメントの所有権が一般的により良い結果を生むことについて、私はあなたに同意する傾向があります。誰かが予告なしに去ることは成功を妨げますか？もちろん。ただし、チーム内の全員がコードベースに関して同じ量の知識を持っている必要があるというふりをするのは素朴で、コードを改善することはありません。コードを保護しようとします。コードの保護は、明らかな理由からビジネスの役割です。コードを保護するためにビジネスが行う労力の長さは、多くの場合、同じように有害になる可能性があります。

チームのすべてのプレイヤーがクォーターバックをプレイできるかどうかを確認していませんか？チームメンバーがコードベース全体に出資していることを確認することは、チーム内のすべてのプレーヤーに満足のいくレベルでクォーターバックをプレイさせようとするのと同じ方針に沿っていると主張します。バックアップはありますか？もちろん…ですが、チームメンバーはチーム内でアイデンティティを持っている必要があります。誰もが同じであると信じることは、異なる種類の痛みを求めることです...

個々のコードの所有権が良いアイデアであることは知りません。少なくとも人々が「これは私のコードであり、私はそれでやりたいことをやる」と言うことができるという意味ではそうではありません。おそらく、個々のコードマネージャーシップが必要だと言った方が良いでしょう。コードはチームが所有する必要がありますが、チームが責任と権限を委任する特定の人物が1人います。

これの理由は、それが全員の責任であれば、誰の責任でもないからです。

次の理由により、個人よりもチームの所有権を支持します。

• プロジェクト全体にわたるコードの一貫性
• コードの議論を促進し、常により良い、より吟味されたソリューションにつながる
• 1人のチームメンバーが具合が悪い（または悪い）場合、コードのセクション全体が遅延の影響を受けません。
• チームメンバーはプロジェクトのすべての部分で作業できます。これにより、開発プロセスにコードレビューを組み込むことができます。

特化は大丈夫です-大規模なコードベースの場合、これは長い目で見れば通信時間をかなり節約できますが、所有権はそうではありません。

つまり、チームにはバグがあるという態度である必要があり、「ああ、Xだけがそのコードに触れることができるので、それは私の問題ではない」と言うべきではありません。チームの一員である場合、可能な場合はコードベース全体のバグを修正し、適切に修正することもあなたの責任です。Xの人がそうするのに最適な選択かもしれませんが、もし彼らがそれをしなければならなかったなら、誰でもそうすることを期待されるべきです。これは当然のように書き込まれるコードが必要ですができますと誘うそれで動作するようにチームメンバーを。厄介なコードはこれを禁止します。そのため、ほとんどの開発者がコードを操作できるので、非常に明確でシンプルなコードに努めてください。ピアレビューを行って、そのままにしておくことをお勧めします。

私はあなたに反対する必要があります。コードベースのチーム所有権は、個々の所有権よりもはるかに優れた選択肢です。

個人所有権の明らかなマイナス面は、ある従業員に何かが起こった場合（解雇、退職、病気など）、本当にきれいなコードを書いていない限り、他の誰かがその従業員を採用するまでに時間がかかることです特に、独自のコードを管理する必要がある場合。

また、チームの所有を容易にするツールが多すぎます。コードレビュー、ソース管理-これらは、コードベース全体にわたるチームの関与を促進するものです。また、コードベースの特定の部分をどのように一人に割り当てるのですか？このファイルを変更できるのはこの人だけだと言いますか？

最後に、コードベースの一部が破損した場合、コードベースの責任者を非難するのは簡単すぎ、さらに多くの問題を引き起こすと思います。

両方のアプローチには緊張があるため、両方が必要だと思います。

コードのいずれかの部分で作業できる人が1人だけの場合、特に開発者が失敗点になるため、成長する場合は特に、会社にとって長期的には非常に悪いことです。一方、開発者は一般的にそのアプローチ（インセンティブ）を好むため、開発者はコードをよく知っているなどの理由で、個々のコード所有権は（願わくば）配信時間を短縮できます。また、時間の問題もあります。ビジネスニーズに応じて特定のプロジェクトに開発者を再配置しますが、毎日それを行う場合、それは恐ろしいことです（開発者が嫌いなだけでなく、切り替えコストが高すぎるため、ほとんどの時間を費やしているためです）何もありません）。

IMO、マネージャーの役​​割の1つは、両者のバランスをとることです。コードレビュー、コーディング標準、一連のツールの標準化も、障害の問題を減らすのに役立ちます。結局、保守可能なコードの主なポイントは、この問題に取り組むことです。

集合的なコードの所有権は、個々のコードの所有権よりも比較にならないほど優れていると思います。

私はトラックの議論に悩まされていません-個人所有モデルでは、所有者の損失は他の誰かが引き継ぐのに必要な時間の点で高価ですが、イベントは償却コストが低いほどまれです。

むしろ、集合的なコードの所有権は直接高品質のコードにつながると思います。これは、2つの非常に単純な理由によるものです。第一に、あなたのプログラマーの中には他のプログラマーほど優れていないものがあり、コードを所有している場合、そのコードは貧弱であることです。優れたプログラマーがアクセスできるようにすると、改善されます。第二に、コードレビュー：誰もがコードを所有している場合、誰もがそれをレビューして改善できます。優秀なプログラマーでさえ、自分のデバイスに任せた場合、サブパーコードを作成します。

これは私の現在のプロジェクトでの経験に基づいています。私たちは集団所有権を実践することを目指していますが、システムの一部は専門になりました-私と他の人はビルドシステムの事実上の所有者です、例えば、入ってくるデータフィードでほとんどの仕事をしている人がいます、画像のインポートなどに取り組んでいる別の男。これらの領域のいくつか（特に、私の領域では、私は告白しなければなりません！）で、コードの品質は深刻に苦しんでいます-チームの他の人々の注意を単に生き残らない間違い、誤解、クラッジ、ハックがあります。

特定のコードの所有権が異なるプログラマー間で定期的に移動する（たとえば、3か月ごと、またはすべてのリリース-おそらくすべての反復？） 。作物の回転に相当するプログラミング。それは楽しいかもしれません。しかし、私は自分で試してみるつもりはありません。

チームコードの所有権は、複数の貢献者が一般的なサブシステムの基本アーキテクチャを理解するほど重要ではないと思います。

たとえば、サーバー製品の管理用Webページを作成するチームが2人います。Javaスクリプトまたはhtmlから直接サーバーでC関数を呼び出すことができるように、カスタムサーバー側スクリプトエンジンを構築しました。私たちの「ウェブ」の人たちが、お互いのウェブページアプリケーションの共同所有者ではなく、このエンジンの使い方を理解することがより重要だと思います。

コードを書いた時点でコードの個々の所有権を取得してから、チームに引き渡すと思います。このようにして、全員が責任を持ち、貢献します。誰もが作成したコーディングエラーを修正する必要があります。コードレビューに加えて、これはより高い標準を作成します。誰も他の人の後をきれいにする仕事を望んでいません。

より多くの責任とより少ない所有権を考えてください。結局のところ、小切手を書いている人はだれでも本当の所有者です。

ジム、私はあなたと一緒にその100％です。私は職場でまったく同じ戦いの真っin中にいるので、あなたの質問に出くわしました。

私が見る方法は、「誰もがそれを所有しているとき、誰もそれを所有していない」です。

私にとって、所有権と責任以上にコード品質に重要な要素はありません。

実生活の例がこれをよく示しています。あなたは私用の芝生とコミュニティの公園のどちらをもっと気にかけますか？かなり明白。

ところで、それは必ずしも「チームの柔軟性」とトレードオフする必要はありません。それは単に、人が何かを所有するとき、それを所有することを意味します。

私にとっては、チームのダイナミクスに依存します。

たとえば、標準、ピアレビュー、系統的テストで統一されていないチームがある場合、またはメンバー間で能力レベルが大きく異なるチームがある場合は、コード所有権のより強力な概念を模索することをお勧めします。よりブラックボックスのモジュラーマインドセットを使用します。

これがないと、たとえば、SOLIDの原則に準拠した慎重に設計されたインターフェイスは、「SOLID」の意味すら知らず、「便利」のために常に新しい折functions的な機能をインターフェイスに追加したい人によってすぐに台無しになります。これは、間違いなく最悪です。

バグを修正するという考えが根本的な問題を理解せずに症状を修正しているずさんな同僚にも対処するかもしれません（例：バグを非表示にして致命的なものを転送するためだけに回避策をコードに入れることでクラッシュレポートに応答しようとする他の人への副作用）。その場合、インターフェイス設計の妨害行為ほど悪くはなく、慎重に構成された単体テストで意図を保護できます。

理想的な解決策は、このオーサーシップと所有権の概念がもはや重要でなくなるまでチームを強化することです。ピアレビューは、コードの品質を向上させるだけでなく、チームワークを向上させることでもあります。標準は一貫性だけでなく、チームワークを改善します。

しかし、ピアレビューを行い、実際にすべての人を基準に適合させることは絶望的であり、多くの絶望的に経験のない批評家をミックスに取り込むシナリオがあります。コードの所有権とチームの所有権のどちらがより優先されるかは、チームが実際に効果的なピアレビューを実行し、実際に全員がその恩恵を受けているように見せることに基づいていると思います（レビュー自体の観点から） 、そしてその結果、考え方と基準がより密接になります）。大規模で、ゆるい、および/または異なるチームでは、これは絶望的に見えるかもしれません。あなたのチームが「分隊」のように機能し、誰が何を書いたのかほとんどわからない場合、単独の所有権は馬鹿げた概念のように見え始めます。

このような理想からはほど遠いシナリオでは、このコード所有権の概念が実際に役立つ場合があります。最悪のシナリオをうまく解決しようとしていますが、一般的にチームワークが作者のコードの周りにフェンスを置くことを望んでいない場合に役立ちます。その場合、チームワークは減少しますが、「チームワーク」がつま先を踏み出すだけの場合は、それがより良い場合があります。