コードの所有権はコードの匂いですか?


27

これは、物議を醸すプログラミングの意見のスレッドでこの答えを読んで以来ずっと考えてきたことです。

あなたの仕事は、自分を失業させることです。

雇用主向けのソフトウェアを作成する場合、作成するソフトウェアは、開発者が理解し、最小限の労力で理解できるように作成する必要があります。適切に設計され、明確かつ一貫して記述され、きれいにフォーマットされ、必要な場所に文書化され、期待どおりに毎日ビルドされ、リポジトリにチェックインされ、適切にバージョン管理されます。

あなたがバスぶつかったり、解雇されたり、解雇されたり、仕事を辞めたりした場合、あなたの雇用主はすぐにあなたに取って代わることができ、次の人があなたの役割に入り、あなたのコードを拾い上げて1週間以内に走ります。彼または彼女がそれを行うことができない場合、あなたは惨めに失敗しました。

興味深いことに、その目標を持っていることが雇用主にとってより価値のあるものであることがわかりました。使い捨てになるように努力すればするほど、彼らにとってより価値のあるものになります。

そして、これは他の質問、例えばこれで少し議論されましたが、私は再びそれを持ち出し、より多くの空白から「それはコードの匂いです!!」という観点から議論したかったのです。まだ深さ。

私は10年間プロの開発者です。私は、適切な新しい開発者が比較的迅速に理解できるようにコードが十分に書かれた仕事を1つ持っていますが、業界のほとんどの場合、非常に高いレベルの所有権(個人とチームの所有権の両方)が普通。ほとんどのコードベースには、新しい開発者がそれらを選択してすばやく作業できるようにするためのドキュメント、プロセス、および「オープン性」が欠けているようです。コードベースを非常によく知っている(「所有している」)誰かが知っている、書かれていない小さなトリックやハックが常にたくさんあるようです。

もちろん、これに関する明らかな問題は次のとおりです:人がやめるか、「バスにぶつかった」場合 または、チームレベルで、チームランチに出かけたときにチーム全体が食中毒になり、全員が死亡した場合はどうなりますか?チームを比較的簡単に新しいランダムな開発者の新しいセットに置き換えることができますか?-私の過去の仕事のいくつかでは、そのことがまったく想像できません。システムには非常に多くのトリックとハックがあり、「知っておく必要がある」だけなので、採用する新しいチームは収益性の高いビジネスサイクル(たとえば、新しい安定したリリース)よりもはるかに長くかかります。要するに、製品を放棄しなければならないとしても、私は驚かないでしょう。

明らかに、チーム全体を一度に失うことは非常にまれです。しかし、これにはもっと微妙で不吉なことがあると思います-これは、このスレッドでこれまで議論したのを見たことがないので、このスレッドを開始することを考えさせたポイントです。基本的に、コードの所有権に対する高いニーズは、技術的な負債の指標であることが非常に多いと思います。システムにプロセス、コミュニケーション、優れたデザイン、多くの小さなトリックやハッキングが欠けていて「知っておく必要がある」などの場合は、通常、システムが次第に深く技術的な負債に陥っていることを意味します。

ただし、コードの所有権は、プロジェクトや会社に対する一種の「忠誠心」として、またあなたの仕事に対する「責任を負う」肯定的な形として提示されることが多いため、完全に非難することは一般的ではありません。しかし同時に、方程式の技術的負債の側面は、コードベースが次第にオープンになり、作業が難しくなることを意味することがよくあります。そして、特に人々が前進し、新しい開発者がその地位に就く必要があるため、技術的な負債(つまり、メンテナンス)コストが高騰し始めます。

ですから、ある意味では、コードの所有権に対する高いレベルのニーズが、一般的なプログラマーの想像力の中で、仕事の匂いとして公然と見られていれば、私たちの職業にとって良いことだと思います。「仕事に責任と誇りを持っている」と見なされるのではなく、「技術的な負債を介して自分自身を定着させ、人工的な職の安全を確保する」と見なすべきです。

そして、テスト(思考実験)は基本的にすべきだと思います:もしその人(あるいはチーム全体)が明日地球の表面から消えたとしたら?これはプロジェクトの巨大な-おそらく致命的な-怪我になりますか、それとも新しい人々を連れて来て、彼らにdoccosとヘルプファイルを読んでもらい、数日間コードを遊んでもらうことができますか?数週間でビジネスを開始します(1か月ほどで完全な生産性に戻ります)。


3
あなたの質問は何ですか?また、「コードのにおい」とは何ですか?
キャメルブルース

2
@CamelBlues:「コードの匂いは、より深い問題を示す可能性があるプログラムのソースコードの症状です。」(Wikipedia)コードのにおいに関するこのサイトの多くの質問のいくつかについては、この検索を参照してください。
Carson63000

4
コードの所有権はコードの匂いの結果ではなく、コードの所有権コードの匂いではありませんか?私は、これはまだこの1を含む他のものと同じ問題だと思う:programmers.stackexchange.com/questions/48697/...
レイ宮坂

1
私は「責任/所有権を取る」!=「コードの所有権」について、最近、コードの所有権がやや悪く、人々が責任を放棄することを許可するのと同じではないというマネージャーとの議論がありました。このマネージャーにとって、コードの所有権は、責任を負うことと同じことを意味していました。
トーマスジェームズ

1
ええ、私はこのQがコードを定義するように思われることを意味するためにコードの所有権を取ったことはありません。所有権を私に持つということは、恐ろしいバスが私のコードを読むことができた後に私を置き換える人を意味します。
エリックReppen

回答:


32

コードの所有権を変える必要があると思います。

  • 責任の観点から、
  • コードスタイル/ハックなどの観点から。

最初のものを奨励する必要があります。低品質のコードとバグの責任者がいない場合、悪いことが起こります。自分のコードに関連するバグを毎回割り当てる必要があるという意味ではありません。コードが正しく記述されていれば、誰でもコードの任意の部分のバグを修正できます。ただし、実行したバグについてフィードバックがない場合は、同じバグを何度も作成します。

コードの所有権は、管理者と開発者の両方、特に開発者にとって非常に役立ちます。3人の開発者がプロ​​ジェクトに取り組んでいる間に製品のバグの80%がコード内にあり、それらのバグの75%がSQLインジェクションに関連していることを知っていれば、次回はコードをより慎重に記述し、データベースクエリを正しく記述するために余分な努力をします。


2番目(コードスタイル/ハッキングなどからのコード所有権)は、ほとんどが悪いことです。それは製品に何をもたらしますか?製品の品質は向上しませんが、ソースコードの均一性低下し、最近の保守が難しくなります。

多くの大規模なプロジェクトでは、人々は同じコードで作業を続けることはありません。そして、ここでは、開発者がバスに襲われるような恐ろしいことについても話しません。この場合、コードの所有権が最初の関心事ではないと思います。しかし、多くのマイナーな考えが起こります:開発から管理または他の仕事への移行、他のプロジェクトの選択、他の作業、または別の言語の使用(プロジェクト内で複数の言語が使用されている場合)など

プロジェクトのコードの一部を別のプロジェクトで再利用することもできます。この別のプロジェクトで作業している開発者は、コードの元の作成者にアドバイスを求めることなく、新しいニーズに合わせてコードの一部を変更したいと考えています。

それはコードの匂いですか?まあ、それはコードの匂いが何を意味するかによります。私にとっては、プロジェクトの全体的な一貫性と正しい管理がすべてです。良いプロジェクトでは、

  • 後でコードを理解しやすくするために、コードスタイルガイドラインが適用されます。
  • 経験豊富な開発者はKISSの原則に違反しないため、経験の浅い同僚が後でソースコードを理解するのに役立ちます。

結論として、コードの所有権はバージョン管理を介して追跡する必要がありますがコードの一部が自分またはチームの他の誰かによって作成されたと言ってはなりません


9

まず、「コード所有権」とは何かを定義する必要があります。


コードの一部(一部)が開発の初期段階にある場合、1人または2人を「所有者」として指定する必要があることがよくあります。

  • 最初は明確な仕様や要件はありません。開発者は自分で情報を収集する必要があります。収集とそれらの調査結果の文書化との間には時間差があります。
  • コードの一部が積極的に変更されている場合、競合する編集を避けます。
  • 「所有者」は、機能の開発の進捗状況を報告できる人です。

通常、タスクごとに1人の所有者がいます。ペアプログラミングで二重所有者が可能です。厳密に指定されていない「コード所有権」なしで実行することは実用的ではありません。

注:開発中の他の問題については、
@ MainMaの回答をご覧ください。そのような場合、「コード所有権」は、より大きな問題の兆候です。つまり、アーキテクチャの最適化されていない選択、コーディングスタイルの不整合、および一般的なコード品質の欠如です。


ピースが記述されてコードベースに受け入れられると(「完了」)、より一般的な「コード所有権」の質問が表示されます。

  • このコード/機能のこの部分に関するすべての質問に答えることができる専門家は誰ですか?
  • この知識は、要件文書、単体テスト、受け入れテスト、変更ログ、プロジェクトWikiなどの有形の成果物に取り込まれていますか?

書面による仕様に形式化するのが難しいドメイン知識(顧客の要件の暗黙の理解、難解なシステムとの互換性の問題など)の一部は常に存在します。したがって、災害イベントが発生した場合、ドメインの知識がある程度失われることが予想されます。

ドメインの知識が失われるとともに、システムの詳細を説明できる専門の回答者も失われます。この側面では、専門家の喪失は普遍的に悪いことです。知識は以前に取得されている必要があります。

これは、「専門家」の存在が悪いことを意味するものではありません。専門家は、書かれた知識の「キャッシュ」であると考えてください。多くの場合、専門家は、書かれた知識を調べて消化するよりも速く質問に答えることができます。


ただし、「コード所有権」とは、プロジェクトのアクティブな開発者が外部者によるコードの変更を防ぐために設定された障壁を指す場合があります。

  • 誰がこのコードを変更できますか?
    • 明らかなバグを修正するには?
    • コードが他の要件を満たせるようにするには?
    • 完全に自分の好みに合わせてコードを書き換えるには?

良い障壁と悪い障壁があります:

  • 良い障壁
    • ドメイン知識-要件とアーキテクチャ/コーディングスタイルをどれだけ理解しているか
    • プログラミングと設計のスキル-プロジェクトの設計とコードの品質を向上させるスキルはありますか
  • 悪い障壁
    • 元の開発者チームに所属していなかったため、変更を加えることはできません。
    • バグ修正のみを歓迎します。機能強化は歓迎されません。

この場合、他のプロジェクトのソースコードを編集する権限はコード所有権に基づいてはなりませんが、メリットに基づいている必要があります。


最後に、@ Graham Leeの回答は、部門化によって引き起こされる知識とアーキテクチャの断片化を指摘しています。

この場合、「コード所有権」は部門化の症状の1つです。2番目の症状は、「他のチームのプロジェクトに対する関心の欠如」です。組織として、マネージャーは、チームや部門間で知識の伝達とコラボレーションを促進するための措置を講じる必要があります。


7

もっと知らないうちに、いくつかの会社(私は一度働いたことがあります)は、機能チームを中心に管理構造を編成します。Windowsクライアント開発者を管理し、インストーラーチームを管理し、バックエンド開発者を管理します。これは、あなたが説明する強力なコード所有権をもたらすだけでなく、ビジネスの仕組みとしてそれをcodeっています。ソフトウェアアーキテクチャを政治的戦いに変えます。

これは問題ですか?これは、アーキテクチャが最適である、または次善になる場合です。(たとえば)インストーラーがクライアントのユースケースである場合、それがチームやマネージャーから制御を奪うため、インストーラーの方が優れているか、開発コストが安いと言うことはできません。機能モジュール間の分割は、エンジニアリング部門の運営方法に関する事実となっており、それらの事実を変更するには多くの混乱が必要です。

[ところで、上記の議論で明確にならない場合、あなたの質問に対する私の答えはイエスです。コードの所有権はコードのにおいです。優れたアイデアを持つ賢い人、または必要なときに利用できる人だけがコードを操作するのを止めることができるからです。明らかに、気まぐれな変更を止めるためのコントロールを持つことは良いことですが、バグを修正する方法を見ることができ、それを行う時間があるエンジニアがいる場合、他の誰かがバグのあるコードを書いたという理由だけでそのエンジニアをブロックするべきではありません。 ]


6

わずかに異なる観点から質問に取り組むことで、コードの所有権はコードの匂いではありません。それは代わりに管理と資源の匂いです。

コードのにおいが何を意味するか考えてください。これは、コードを見たときに、コードやソフトウェアの設計で何かが正しくないことを示すメタファーですが、問題は、何に指を置くことができるほど明白ではないかもしれません正確な問題はあるかもしれませんが、おそらくあなたはそれにもかかわらず良い考えを持っているでしょう。あなたの家では、何か悪臭がする場合、問題の原因を突き止めるまで鼻をたどり、それから何かをします。同様に、コードに問題がある場合は、問題が少なくなるまで、または一部の人が言うように、美しくまたは巧妙に作成されるまで、コードを調査して変更します。

一方、コードの所有権は深刻な問題になる可能性があります。これは、監視の欠如と、コードの所有者が去ると、そのコードとそれが解決する特定の問題に関する知識が企業で利用できなくなるリスクを示唆しています。これは実際のコード自体とは関係ありません。基本的には、データのバックアップを保持するのと同じ方法でリスク管理の状況に帰着し、会社の他の領域のタスク所有権またはドキュメント所有権と同じように適用されます。

他のビジネス上の問題を匂いとして説明するのは良いことだと思いますが、匂いがあるからといって、それが特にコードに関係していることを意味するものではありません。


1

コード所有権は、他の人が将来あなたのコードで作業することを理解した上で、あなたが書いたコードに対して個人的な責任を取ることと定義します。このように考えると、a)そのモジュールのバグを追跡できる可能性があり、b)チームメンバーが将来コードを変更するのに苦労する可能性があるため、ハックを書く可能性は低くなります。

数か月前にブログ投稿を書きました。コード所有権がないと、コードベースはしばしばCommonsの悲劇の餌食になると主張しました。

あなたのコード所有権の定義から、著者だけが作業できるコードを持つのは悪いことに同意します。


「コードの傾向」、または「コードシッティング(ベビーシッター)」に似ています。あなたの答えのすべてに同意します。
-Mawg
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.