個人コードの所有権は重要ですか？
私は、コードベース全体のチームの所有権が、コンポーネントの個々の所有権よりも優れているかどうかについて、一部の同僚と議論の真っ最中です。
私はチームのすべてのメンバーにコードベースのほぼ同じシェアを割り当てることを強く支持しています。それは人々が彼らの創造に誇りを持ち、バグスクリーナーに着信チケットを割り当てる最初の場所を明らかに与え、そして「壊れたウィンドウ症候群」を軽減するのを助けます。
また、特定の機能に関する知識が1つ（または2つ）のチームメンバーに集中し、バグの修正がはるかに容易になります。
何よりも、委員会ではなく、多くの情報を提供する1人の人物による主要な決定について最終決定を下します。
他の誰かがあなたのコードを変更したいのであれば、私は許可を要求することを主張していません。たぶん、コードレビューを常にオーナーにしてもらいたいです。また、知識サイロを構築することを提案しているわけでもありません。この所有権については、何も排他的であってはなりません。
しかし、これを同僚に提案すると、確かに私は予想よりもはるかに多くの反発を受けました。
だから私はコミュニティに質問します：大規模なコードベースのチームと協力することについてあなたの意見は何ですか？集団的所有権を慎重に維持することについて私が見逃していることはありますか？
チームの所有権は、長期的にははるかに有益であると思います。
最小限の人数で知識を集中することが理想的とは言えない理由を理解するには、次の2つのシナリオを検討する必要があります。
- チームメンバーが不幸な事故に遭遇
- チームメンバーがより良い雇用機会に会う
当然、特定のセクションを書く人/人々は、それについてのより大きな知識を持っていますが、それらを唯一の知識サイロにする誘惑に屈しないでください。 Silosは、長期的な苦痛によって短期的な勝利をもたらします。
コードのセクションを個別に所有していないからといって、それを書いたからといって、「自分の作品に誇りを持っている」などの側面がなくなるわけではありません。チームの所有権を持っているとは思いません。記述されたコードの所有権に関する個人的な感情を減らします。
最終的に、チームがコードを所有します。しかし、あなたが言及したすべての理由のために、私たちはコードの特定の部分のために個々の著者を指定しました。各作成者は、コードの一部に対して主な責任を負い、コードベース全体に対して副次的な責任を負います。
コードベースの一部に問題がある場合は、修正のためにコードを最初に作成した人に戻ってみます。もちろん、他のチームメンバーが修正を適用するのを妨げるものはありません。すべてのチームメンバーは、他の人のコードに精通していることが求められます。ただし、常に最初に元の作成者から修正を取得するように努めています。結局、彼らはコードを書きました。彼らはそれに最も精通しているものです。
私はチーム環境で働いてきましたが、人々は自分が書いたものに対する所有権を感じなかったため、優れたコードを書くことを強いられず、平均的なコードに過ぎませんでした。
私は、製品についての知識を広める理由についてビジネススタンスから同意しますが、現実は、何でも特定の領域に努力を集中する個人は、時間の経過とともに、その特定の領域にはるかに精通するようになるということです。
これを無視することは科学を無視することです。残念ながら、脳は遭遇するすべてのものを保持することができません。特定の瞬間に何が有効で価値があるかを思い出しますが、ストレージは時間とともに減少します。
より大きなコードベース内の特定のモジュールまたはコンパートメントを所有することで、一般により良い結果が得られることについて、私はあなたに同意する傾向があります。誰かが予告なしに去ると、成功が妨げられますか？もちろん。しかし、チーム内のすべての人がコードベースに関して同じ量の知識を持っている必要があるというふりをするのは単純であり、コードを改善するために何もしません。コードを保護しようとします。コードを保護することは明らかな理由でビジネスの役割です。多くの場合、コードを保護するために企業が費やす努力は、同じように有害になる可能性があります。
あなたはチームのすべてのプレーヤーがクォーターバックをプレーできることを確認していませんか？チームメンバーがコードベースに関与するようにすることは、チーム内のすべてのプレーヤーに満足のいくレベルでクォーターバックをプレイさせることと同じことであると私は主張します。バックアップはありますか？確かにあなたはそうします...しかし、チームメンバーはチーム内でアイデンティティを持つべきです誰もが同じだと信じることは、異なる種類の痛みを求めることです...
個別のコードownershipが良い考えかどうかはわかりません。少なくとも、「これは私のコードです。私がやりたいことをやります」と言うことができるという意味ではありません。たぶん、あなたは個別のコードを持つべきだと言う方がいいmanagership：コードはチームが所有するべきであるが、チームがそれに対する責任と権限を委任する特定の人物がいる。
これは、それが全員の責任である場合、誰の責任でもないためです。
以下の理由により、個人よりもチームの所有権を支持します。
- プロジェクト全体のコードの一貫性
- コードのディスカッションを促進します。これは常に、より良い、より綿密なソリューションにつながります
- チームメンバーの1人が病気になった（または悪化した）場合、コードのセクション全体が遅延の影響を受けない
- チームメンバーは、プロジェクトのすべての部分に取り組むことができます。これにより、コードレビューを開発プロセスに組み込むことができます。
専門化は問題ありません-大規模なコードベースの場合、これは長期的にはコミュニケーションの時間をかなり節約できますが、所有権はそうではありません。
つまり、その態度はteamにバグがあることであり、誰も「ああ、Xだけがそのコードに触れることができるので、私の問題ではない」と言うべきではありません。あなたがチームの一員である場合、可能であればコードベース全体のバグを修正し、適切に修正するのもあなたの責任です。人Xがそうするための最良の選択かもしれませんが、彼らがそれをしなければならなかった場合、誰もがそうすることを期待されるべきです。これには当然、コードをallowsおよびinvitesチームメンバーが操作するように記述する必要があります。危険なコードがあるとこれが禁止されます。そのため、ほとんどの開発者がコードで作業できるため、非常に明確でシンプルなコードを目指して努力します。 keepにピアレビューを行ってください。
私はあなたに同意しなければなりません：コードベースのチーム所有権は個人所有権よりもはるかに良いオプションです。
個人の所有権の明らかな欠点は、1人の従業員に何かが起こった場合（解雇、退職、病気になるなど）、その従業員がreallyクリーンなコードを記述しない限り、しばらく時間がかかることです他の誰かがその人のコードを採用するため、特に彼らが自分のコードも管理する必要がある場合。
また、チームの所有権を容易にするツールが多すぎます。コードレビュー、ソース管理–これらは、コードベース全体を通じてチームの関与を促進するものです。さらに、コードベースの特定の部分を1人の人にどのように割り当てますか？この人だけがこのファイルを変更できると言いますか？
最後に、コードベースの一部が壊れた場合、それを担当した人物を責めるのは簡単すぎるため、問題がさらに増えると思います。
両方のアプローチには緊張関係があるので、両方が必要だと思います。
コードの一部について作業できる人が1人しかいない場合、特に開発者が成長するかどうかに関係なく、企業にとって長期的にはそれは本当に悪いことです。一方、個々のコードの所有権は（できれば）配信時間の短縮を可能にします。これは、開発者が一般にそのアプローチ（インセンティブ）を好むため、開発者がコードを非常によく知っているためなどです。時間の問題もあります。ビジネスニーズに応じて特定のプロジェクトに開発者を再割り当てすることはできますが、日常的に行うと、それは恐ろしいことです（開発者がそれを嫌うだけでなく、スイッチのコストが高すぎるため、ほとんどの時間を費やしているため）何も）。
IMO、マネージャーの役割の1つは、両者の良いバランスを見つけることです。コードのレビュー、コーディング標準、一連のツールの標準化も、障害の問題を減らすのに役立ちます。結局のところ、保守可能なコードの主なポイントは、この問題に取り組むことです。
集団的なコードの所有権は、個々のコードの所有権よりも比較にならないほど優れていると思います。
私はトラックの議論に悩まされていません-個人所有モデルでは、所有者の損失は誰かが引き継ぐのに必要な時間の点で高価ですが、このイベントは非常にまれなので、償却後のコストは低くなります。
むしろ、集団的なコードの所有権は直接高品質のコードにつながると思います。これは2つの非常に単純な理由によるものです。第一に、辛い真実はあなたのプログラマーの何人かが他のプログラマーほど良くないということであり、彼らがコードを所有している場合、そのコードは貧弱になるでしょう。優れたプログラマーにアクセスを許可すると、改善されます。第二に、コードレビュー：誰もがコードを所有している場合、誰でもコードをレビューして改善できます。優秀なプログラマーでも、自分のデバイスに任せれば、準標準コードを作成します。
これは私の現在のプロジェクトでの経験に基づいて言っています。私たちは集団的所有権を練習することを目指していますが、システムの一部が特殊化しています-私と別の人は事実上ビルドシステムの所有者です。たとえば、受信データフィードでほとんどの作業をしている人がいます、画像のインポートなどに取り組んでいる別の人。それらのいくつかの領域（特に、私の領域では、私は告白しなければなりません！）で、コードの品質は深刻な影響を受けています。
特定のコードの所有権が異なるプログラマー間で定期的に（たとえば、3か月ごと、またはリリースごとに、おそらく反復ごとに）移動する個別のコード所有権を持つことにより、集団的なコード所有権のいくつかの利点を得ることができることに注意します。 。クロップローテーションと同等のプログラミング。それは楽しいかもしれません。でも、私は自分で試すつもりはありません。
チームコードの所有権は、一般的なサブシステムの基本的なアーキテクチャを複数の寄稿者に理解させるほど重要ではないと思います。
たとえば、私たちのチームには、サーバー製品の管理Webページを作成している人が2人います。 Javaスクリプトまたはhtmlから直接サーバー上でC関数を呼び出すことができるように、カスタムサーバーサイドスクリプトエンジンを構築しました。 "web"みんなは、他のWebページアプリケーションの共同所有者ではなく、このエンジンの使い方を理解しています。
ジム、私はあなたと一緒に100％います。私は私の職場でまったく同じ戦いの真っ最中です-そのため私はあなたの質問に出くわしました。
私がそれを見る方法は、「誰もがそれを所有するとき、誰もそれを所有しない」です。
私にとって、コードの品質には、所有権と責任以外に重要な要素はありません。
実際の例はこれをよく示しています。あなたはどちらをよりよく世話しますか：あなたの私有の芝生またはコミュニティの公園？かなり明白。
ところで、それは必ずしも「チームの柔軟性」とトレードオフする必要はありません。それは単に、人が何かを所有しているときに、それを所有していることを意味します。
私にとってそれはあなたのチームのダイナミクスに依存します。
たとえば、標準、ピアレビュー、系統的テストによって統一されていないチームがある場合、またはメンバー間で能力レベルが大きく異なるチームがある場合、コードの所有権についてより強い概念を模索することをお勧めします。よりブラックボックスなモジュラーマインドセットで。
これがないと、たとえば、SOLIDの原則に準拠した注意深く設計されたインターフェースは、「SOLID」の意味すら知らず、常に新しい折衷的な関数を追加したい人によってすぐに台無しにされる可能性があります。 「便利さ」のためのインターフェースへ、例えばこれは断然、最悪です。
また、根本的な問題を理解せずにバグを修正するという考えが症状を修正しているずさんな同僚に対処することもできます（例：バグを非表示にして致命的なものを転送するだけの回避策をコードに組み込んでクラッシュレポートに対応しようとする場合）他の誰かへの副作用）。その場合、それはインターフェース設計サボタージュほど悪くなく、慎重に作成された単体テストで意図を守ることができます。
理想的な解決策は、作者と所有権のこの概念がもはや重要ではなくなったところまで、チームを強化することです。ピアレビューは、コードの品質を向上させることだけでなく、チームワークを向上させることでもあります。標準は一貫性だけでなく、チームワークを向上させます。
それでも、ピアレビューを行って実際に全員を標準に準拠させることは、絶望的であり、絶望的に経験のない多くの批評家を混ぜ合わせるシナリオがあります。コードの所有権とチームの所有権のどちらを優先するかは、チームが実際に効果的なピアレビューを実行し、実際に全員にレビューの恩恵を受けられるようにする能力に基づいていると思います（レビュー自体に関して） 、そしてその結果としてマインドセットと基準がより緊密になる。大規模でルーズな、または異種のチームでは、これは絶望的に見えるかもしれません。チームが「分隊」のように機能でき、誰が何を書いたかさえほとんど分からない場合、唯一の所有権はばかげた概念のように見え始めます。
このような理想的とはほど遠いシナリオでは、このコード所有権の概念が実際に役立つ場合があります。これは最悪のシナリオをうまく利用しようとしていますが、チームワークが一般に著者のコードの周りにフェンスを置くことが望めない場合に役立ちます。その場合、それはチームワークを減少させますが、「チームワーク」がつま先だけにつながる場合、それはより良いことです。
コードを書いた時点でコードの個人的な所有権を取得し、それをチームに引き渡すと思います。このように、誰もが責任を持って貢献します。誰もが作成したコーディングの失敗を修正する必要があります。コードレビューとともに、これはより高い基準を作成します。誰もが他の人の後を片付ける仕事を望んでいません。
より多くの責任とより少ない所有権を考えてください。結局のところ、小切手を書いている人は誰でも本当の所有者です。