コードの所有権はコードの匂いですか？
これは、私が読んでからずっと考えていたものです 物議を醸すプログラミング意見スレッドでのこの回答 ：
あなたの仕事は、仕事から抜け出すことです。
雇用主向けのソフトウェアを作成する場合、作成するソフトウェアはすべて、開発者が選択して最小限の労力で理解できるような方法で作成する必要があります。適切に設計され、明確かつ一貫して記述され、きれいにフォーマットされ、必要な場所に文書化され、期待どおりに毎日ビルドされ、リポジトリにチェックインされ、適切にバージョン管理されます。
あなたが バスに当たる を取得した場合、解雇された、解雇された、または職を離れた場合、雇用主は一瞬であなたを置き換えることができ、次の男があなたの役割に踏み込むことができますあなたのコードをアップし、一週間以内に稼働し始めます。彼または彼女がそれをすることができないならば、あなたは惨めに失敗したでしょう。
興味深いことに、その目標を持つことで、雇用主にとって私はより価値のあるものになりました。使い捨てに努力すればするほど、彼らにとって価値あるものになります。
そして、それは this one などの他の質問で少し議論されましたが、私はより多くの点から議論するためにもう一度取り上げたいと思いました空白（コードの匂い!! "の観点-これは実際にはまだ詳しく説明されていません。
私は10年間プロの開発者をしてきました。私は、まともな新しい開発者が比較的すぐに取り上げられるようにコードが十分に記述されている仕事を1つ受けましたが、ほとんどの場合、業界では、非常に高いレベルの所有権（個人とチームの所有権の両方）が規範。ほとんどのコードベースには、ドキュメント、プロセス、および「オープン性」が不足しているようです。そのため、新しい開発者は、それらを取得してすぐに作業を開始できます。コードベースをよく知っている（「所有している」）誰かだけが知っている、多くの未記述の小さなトリックやハックが常にあるようです。
もちろん、これに関する明らかな問題は、その人がやめたり、「バスにぶつかった」としたらどうでしょうか。または、チームレベルで：チームランチに出かけたときにチーム全体が食中毒になり、全員が死亡した場合はどうなりますか？比較的簡単に、チームを新しいランダムな開発者の新しいセットに置き換えることができますか？ -私の過去の仕事のいくつかでは、それがまったく起こっているとは想像できません。システムはトリックとハックでいっぱいなので、「知っておく必要がある」ので、採用する新しいチームは、収益性の高いビジネスサイクルよりもはるかに長くかかります（たとえば、新しい安定したリリース）物事を再び進めるために。一言で言えば、その製品が放棄されなければならないと私は驚かないでしょう。
明らかに、一度にチーム全体を失うことは非常にまれです。しかし、これにはもっと微妙で不吉なことがあると思います。これが私がこのスレッドを始めようと思ったきっかけです。基本的に：コード所有権の高い必要性は、技術的負債の指標であることが多いと思います。システムにプロセス、コミュニケーション、優れたデザイン、たくさんの小さなトリックやハックが不足している場合は、「知っておく必要がある」など-通常、システムがますます深くなる技術的負債に陥っていることを意味します。
しかし、問題は-コードの所有権は、プロジェクトや会社に対する一種の「忠誠心」として、つまり作業に対する「責任を負うこと」の前向きな形として提示されることが多いため、あからさまに非難するのは不人気です。しかし同時に、方程式の技術的な負債の側面は、コードベースのオープン性が徐々に低下し、作業がより困難になることを意味します。そして、特に人々が前進し、新しい開発者が代わりをしなければならないとき、技術的負債（つまり、メンテナンス）のコストが急上昇し始めます。
したがって、ある意味では、コードの所有権に対する高いレベルの必要性が公然と（人気のあるプログラマーの想像で）仕事の匂いと見なされれば、私たちの職業にとっては良いことだと私は実際に思います。それは、仕事において「責任と誇りを持つ」と見なされるのではなく、「技術的借金によって自分自身を定着させ、人工的な雇用保障を生み出す」と見なされるべきです。
そして、テスト（思考実験）は基本的には次のようになるべきだと思います。人（または実際にはチーム全体）が明日地球の表面から消えてしまうとしたらどうでしょう。これは巨大な-おそらく致命的な-プロジェクトへの傷害でしょうか、それとも新しい人々を招いてdoccosとヘルプファイルを読んでもらい、数日間コードをいじってもらい、それから戻ってくることができますか？数週間でビジネスを再開できますか？
コードの所有権を変える必要があると思います。
- 責任の観点から、
- コードスタイル/ハックなどの観点から。
最初のものは奨励されなければなりません。 低品質のコードやバグの責任者がいない場合、悪いことが起こります。これは、自分のコードに関連するバグを毎回割り当てなければならないという意味ではありません。コードが正しく記述されていれば、だれでもコードのどの部分でもバグを修正できます。しかしバグに関するフィードバックがない場合は、同じバグが何度も発生します。
コードの所有権は、マネージャーと開発者の両方、特に開発者の多くに役立つ可能性があります。私たちがプロジェクトに取り組んでいる3人の開発者の間に、製品のバグの80％が私のコードにあり、それらのバグの75％がSQLインジェクションに関連していることを知っている場合、次回はより慎重にコードを記述します。データベースクエリを正しく作成するために特別な努力をしてください。
2番目のもの（コードスタイル/ハックなどからのコード所有権）は、ほとんどの場合悪いことです。それは製品に何をもたらしますか？製品の品質は向上しませんが、ソースコードの均一性が低下し、最近の維持が困難になります。
多くの大規模なプロジェクトでは、人々は一生同じコードに取り組んでいるわけではありません。そして、ここでは、バスに襲われた開発者のような恐ろしいことについても話しません。この場合、コードの所有権が最初の問題であるとは思いません。しかし、マイナーな考えがたくさん起こります。人々は、開発から管理や他の仕事に移ったり、他のプロジェクトを選択したり、他のものに取り組んだり、別の言語の使用を開始したりします（プロジェクト内で複数の言語が使用されている場合）など。
プロジェクトのコードの一部を別のプロジェクトで再利用することもできます。この別のプロジェクトに取り組んでいる開発者は、コードの以前の作成者にアドバイスを求めることなく、新しいニーズに合わせてコードの一部を変更したいと考えています。
コード臭？まあ、それはあなたがコードのにおいによって何を意味するかに依存します。私にとって、それはすべてプロジェクトの全体的な一貫性と正しい管理についてです。良いプロジェクトでは
- 後でコードを理解しやすくするために、コードスタイルのガイドラインが適用されます。
- より経験豊富な開発者はKISSの原則に違反しないため、経験の浅い同僚によるソースコードの理解に役立ちます。
結論として、コードの所有権はバージョン管理を通じて追跡する必要がありますが、コードの一部があなたやチームの他の誰かによって作成されたとは言えません。
最初に、「コード所有権」とは何かを定義する必要があります。
コードの一部（一部）が開発の初期段階にある場合、多くの場合、1人または2人を「所有者」として指定する必要があります。
- 最初は明確な仕様や要件はなく、開発者は自分で情報を収集する必要があります。コレクションとそれらの調査結果の文書化には時間的なギャップがあります。
- コードの一部がアクティブに変更されているときに、編集の競合を回避します。
- 「所有者」は、機能の開発の進捗状況を報告できる人です。
通常、タスクごとに1人の所有者がいます。二重所有者はペアプログラミングで可能です。狭く指定された「コード所有権」なしでそれを行うのは現実的ではありません。
注：
開発中のその他の問題については、@ MainMaの answer を参照してください。これらの場合、「コード所有権」は、より大きな問題の症状です。つまり、アーキテクチャの選択が最適ではない、コーディングスタイルの不整合、および一般にコード品質の欠如です。
作品が書かれてコードベースに受け入れられると（「完了」）、より一般的な「コード所有権」の質問が表示されます。
- このコード部分/機能のこの部分に関するすべての質問に答えることができるエキスパートは誰ですか？
- この知識は、要件ドキュメント、単体テスト、受け入れテスト、変更ログ、プロジェクトWikiなどの具体的な成果物に取り込まれていますか？
記述された仕様に形式化するのが難しいドメインの知識の一部（顧客の要件の暗黙の理解、難解なシステムとの互換性の問題など）は常に存在します。したがって、災害イベントが発生すると、ドメインの知識が失われることが予想されます。
ドメインの知識が失われるとともに、システムの詳細を説明できる専門の回答者も失われます。この側面では、専門家の喪失は一般的に悪いことです。知識は以前に取得されているはずです。
これは、「専門家」の存在が悪いことを意味するものではありません。専門家を、書かれた知識の「キャッシュ」であると見なしてください。多くの場合、専門家は、書かれた知識を調べて消化するよりも速く質問に答えることができます。
ただし、「コード所有権」とは、プロジェクトのアクティブな開発者が外部者がコードを変更できないようにするために設定された障壁を指す場合があります。
- このコードを変更できるのは誰ですか？
- 明らかなバグを修正するには？
- コードが他のいくつかの要件を満たすようにするには？
- 自分の好みに合わせてコードを完全に書き直すには？
良い障壁と悪い障壁があります。
- 良い障壁
- ドメイン知識-要件とアーキテクチャ/コーディングスタイルをどの程度理解しているか
- プログラミングとデザインのスキル-プロジェクトのデザインとコードの品質を向上させるスキルはありますか
- 悪い障壁
- あなたは元の開発者チームにいなかったので、変更を加えることはできません。
- バグ修正のみを歓迎します。機能強化は歓迎されません。
この場合、他のプロジェクトのソースコードを編集する特権は、コード所有権に基づくべきではなく、メリットに基づくべきです。
最後に、@ Graham Leeの answer は、部門化によって引き起こされる知識とアーキテクチャの断片化を示しています。
この場合、「コード所有権」は部門化の症状の1つです。 2番目の症状は、「他のチームのプロジェクトへの関心の欠如」です。マネージャーは、組織として、チームや部門間の知識の伝達とコラボレーションを促進するための対策を講じる必要があります。
もっと油断なく、一部の企業（私は1人で働いたことがあります）は、機能的なチームを中心に管理構造を編成します。Windowsクライアント開発者の管理、インストーラーチームの管理、バックエンド開発者の管理などです。これは、あなたが説明する強力なコード所有権をもたらすだけでなく、ビジネスの動作方法としてもそれを保証します。ソフトウェアアーキテクチャを政治的な闘争に変えます。
これは問題ですか？それは、アーキテクチャが最適であるか、最適ではなくなる場合です。 （たとえば）インストーラーがクライアントのユースケースにすぎない場合、インストーラーの方が優れていたり、開発コストが安いとは言えません。これは、チームとそのマネージャーからコントロールを奪うためです。機能モジュール間の分割は、エンジニアリング部門の運営方法に関する事実となっており、それらの事実を変更するには多くの混乱が伴います。
[ところで、上記の議論ではっきりしない場合は、質問に対する私の答えは「はい」です。コードの所有権は、コードの匂いです。なぜなら、それは、優れたアイデアを持つ賢い人々、またはコードで作業する必要があるときに利用可能な人々さえも停止する可能性があるためです。気まぐれな変更を停止するためのコントロールがあることは明らかですが、バグを修正する方法を見ることができるエンジニアがいて、それを行う時間がある場合は、誰かがバグのあるコードを書いたからといって、そのエンジニアをブロックしないでください。 ]
コードの所有権はコードの匂いではなく、少し異なる視点からの質問に取り組みます。代わりに、管理とリソースsmellです。
コードの匂いが何を意味するか考えてください。これは、コードを見たときに、コードやソフトウェアの設計に問題があることを伝えるメタファーですが、問題を明確にできないため、何が問題なのかを理解できません。正確な問題はあるかもしれませんが、おそらくあなたは良い考えを持っています。あなたの家では、何か臭いがあれば、問題の原因を突き止めるまで鼻をたどり、それから何かをします。同様に、コードに問題がある場合は、調査して、問題が少なくなるまで、またはbeautifulまたはwell-craftedのように変更します。
一方、コードの所有権は深刻な問題になる可能性があります。これは、監視の欠如、およびコードの所有者が去った場合、コードに関する知識とコードが解決する特定の問題が会社で利用できなくなるリスクを示唆しています。これは実際のコード自体とは関係ありません。それは基本的に、データのバックアップを保持するのと同じようにリスク管理状況に帰着し、会社の他の領域におけるタスクの所有権またはドキュメントの所有権と同様に適用されます。
他のビジネス上の問題をsmellsとして説明することは問題ないと思いますが、-smellがあるからといって、特にコードに関係しているという意味ではありません。