タグ付けされた質問 「code-ownership」

私のチームメイトの1人はITショップのすべての取引のジャックであり、私は彼の洞察を尊重しています。 ただし、彼は時々頭を使わずに私のコードをレビューします（彼はチームリーダーの2番目の指揮官なので、それは予想されています）。そのため、時々、彼は最終目標を完了する前に私の変更をレビューし、すぐに変更を加えます。 また、3か月以上前のコードの一部に不要な改善を加えた場合もあります。 これにはいくつかの理由があります。 間違いを修正する機会が常に与えられるとは限らない 彼は、彼が混乱しているときに私が何を達成しようとしていたかを尋ねる時間をとっていないので、テストや変更に影響を与える可能性があります 彼のコードが読めるとは限らない 期限は問題ではなく、彼の現在のワークロードは、コードの変更を確認する以外に私のプロジェクトでの作業を必要としません。 とにかく、私は過去に彼が私のコードの所有権を取得できるように変更したい何かを私の仕事で見た場合、私に投稿してくださいと言いました（多分私は「欠点」と言うべきでした）、彼は応答しませんでした。 彼に私に彼の変化を説明するように頼むとき、私は攻撃的になるかもしれないと恐れています。 彼は自分を守る静かな人ですが、彼の行動は続きます。私たちはチームであるため、私は彼にコードの変更を禁止したくありません（できませんでしたが）。 説明を追加： 1つの開発ブランチを共有しています。重要な作業を失うリスクがあるため、すべての変更が1つのタスクを完了するまで待機しません。したがって、変更を確実にビルドし、何も壊さないようにします。 私の懸念は、チームメイトが彼の変更の背後にある理由や目的を説明していないことです。私は彼が私の祝福を必要とするべきではないと思うが、私たちがアプローチに同意しない場合、私たちが長所と短所を議論し、両方が何が起こっているかを理解したら決定を下すことが最善だと思った。 これはチームリーダーとはまだ話し合っていません。必要でない限り、経営陣が関与することなく個人的な意見の不一致を解決したいからです。私の懸念は私たちの仕事に対する脅威というよりも個人的な問題のように思われたので、チームリーダーを煩わせないことにしました。私は、コードレビュープロセスのアイデアに取り組んでいます。これは、私のペットの気持ちをすべて気にすることなく、より組織的なコードレビューのメリットを促進するためです。

71 refactoring  teamwork  communication  code-ownership 

私が所属するチームは、当社のプラットフォームと統合するために会社のパートナーが使用できるコンポーネントを作成します。 そのため、（サードパーティの）依存関係を導入する際には細心の注意を払う必要があることに同意します。現在、サードパーティの依存関係はなく、フレームワークの最も低いAPIレベルを維持する必要があります。 いくつかの例： フレームワークの最も低いAPIレベル（.NET標準）を維持する必要があります。この背後にある理由は、その非常に低いAPIレベルのみをサポートする新しいプラットフォームがいつか登場する可能性があるということです。 JSONを（デ）シリアライズするための独自のコンポーネントを実装しており、JWTでも同じことを実行中です。これは、フレームワークAPIの上位レベルで利用可能です。 標準ライブラリのHTTP実装に依存したくないため、標準ライブラリのHTTPフレームワークのラッパーを実装しました。 同じ理由で、XMLとの間でマッピングするためのコードはすべて「手作業で」記述されます。 私たちはそれをやりすぎだと感じています。これは私たちの速度に大きな影響を与えると思うので、これにどう対処するのか疑問に思っています。

54 architecture  .net  dependencies  third-party-libraries  code-ownership 

チームに新しい開発者がいます。アジャイル方法論は、私たちの会社で使用されています。しかし、開発者には別の経験があります。コードの特定の部分を特定の開発者に割り当てる必要があると考えています。したがって、1人の開発者がプロ​​グラムプロシージャまたはモジュールを作成した場合、プロシージャ/モジュールのすべての変更は自分だけが行うのが正常であると見なされます。 プラス面では、おそらく提案されたアプローチでは、各開発者がコードの自分の部分をよく知っており、修正を迅速に行うため、共通の開発時間を節約できます。欠点は、開発者がシステムを完全に知らないことです。 このアプローチは、中規模システム（ソーシャルネットワークサイトの開発）でうまく機能すると思いますか？

50 project-management  code-ownership 

私は、コードベース全体のチームの所有権が、コンポーネントの個々の所有権よりも優れているかどうかについて、一部の同僚と議論している最中です。 私は、チームのすべてのメンバーにコードベースのほぼ等しいシェアを割り当てることを強く支持しています。これにより、人々は自分の作成に誇りを持ち、バグスクリーナーに着信チケットを割り当てるための明らかな最初の場所を与え、「壊れたウィンドウ症候群」を軽減するのに役立ちます。 また、特定の機能に関する知識を1人（または2人）のチームメンバーに集中させ、バグの修正をはるかに容易にします。 何よりも、委員会ではなく、多くの意見を持っている一人の人との主要な決定について最終決定権を置きます。 他の誰かがあなたのコードを変更したい場合、許可を要求することを支持していません。多分、コードのレビューは常に所有者に委ねてください。また、知識のサイロを構築することもお勧めしません。この所有権について排他的なものはないはずです。 しかし、同僚にこれを提案したとき、私は予想以上に多くのプッシュバックを得ました。 だから私はコミュニティに尋ねます：大規模なコードベースでチームと協力することについてのあなたの意見は何ですか？集団所有権を慎重に維持することに関して私が逃しているものはありますか？

48 team  organization  code-ownership 

私たちは集団コードの所有権を実践しています。私の理解では、これは開発者がコード行を変更して機能を追加したり、バグを修正したり、バグを修正したり、設計を改善したりできることを意味します。 しかし、まだチームにいる開発者からのコードの完全な書き換えについてはどうでしょうか？最初に彼に尋ねるべきですか？ベストプラクティスは何ですか？

40 programming-practices  code-ownership 

これは、物議を醸すプログラミングの意見のスレッドでこの答えを読んで以来ずっと考えてきたことです。 あなたの仕事は、自分を失業させることです。 雇用主向けのソフトウェアを作成する場合、作成するソフトウェアは、開発者が理解し、最小限の労力で理解できるように作成する必要があります。適切に設計され、明確かつ一貫して記述され、きれいにフォーマットされ、必要な場所に文書化され、期待どおりに毎日ビルドされ、リポジトリにチェックインされ、適切にバージョン管理されます。 あなたがバスにぶつかったり、解雇されたり、解雇されたり、仕事を辞めたりした場合、あなたの雇用主はすぐにあなたに取って代わることができ、次の人があなたの役割に入り、あなたのコードを拾い上げて1週間以内に走ります。彼または彼女がそれを行うことができない場合、あなたは惨めに失敗しました。 興味深いことに、その目標を持っていることが雇用主にとってより価値のあるものであることがわかりました。使い捨てになるように努力すればするほど、彼らにとってより価値のあるものになります。 そして、これは他の質問、例えばこれで少し議論されましたが、私は再びそれを持ち出し、より多くの空白から「それはコードの匂いです!!」という観点から議論したかったのです。まだ深さ。 私は10年間プロの開発者です。私は、適切な新しい開発者が比較的迅速に理解できるようにコードが十分に書かれた仕事を1つ持っていますが、業界のほとんどの場合、非常に高いレベルの所有権（個人とチームの所有権の両方）が普通。ほとんどのコードベースには、新しい開発者がそれらを選択してすばやく作業できるようにするためのドキュメント、プロセス、および「オープン性」が欠けているようです。コードベースを非常によく知っている（「所有している」）誰かが知っている、書かれていない小さなトリックやハックが常にたくさんあるようです。 もちろん、これに関する明らかな問題は次のとおりです：人がやめるか、「バスにぶつかった」場合 または、チームレベルで、チームランチに出かけたときにチーム全体が食中毒になり、全員が死亡した場合はどうなりますか？チームを比較的簡単に新しいランダムな開発者の新しいセットに置き換えることができますか？-私の過去の仕事のいくつかでは、そのことがまったく想像できません。システムには非常に多くのトリックとハックがあり、「知っておく必要がある」だけなので、採用する新しいチームは収益性の高いビジネスサイクル（たとえば、新しい安定したリリース）よりもはるかに長くかかります。要するに、製品を放棄しなければならないとしても、私は驚かないでしょう。 明らかに、チーム全体を一度に失うことは非常にまれです。しかし、これにはもっと微妙で不吉なことがあると思います-これは、このスレッドでこれまで議論したのを見たことがないので、このスレッドを開始することを考えさせたポイントです。基本的に、コードの所有権に対する高いニーズは、技術的な負債の指標であることが非常に多いと思います。システムにプロセス、コミュニケーション、優れたデザイン、多くの小さなトリックやハッキングが欠けていて「知っておく必要がある」などの場合は、通常、システムが次第に深く技術的な負債に陥っていることを意味します。 ただし、コードの所有権は、プロジェクトや会社に対する一種の「忠誠心」として、またあなたの仕事に対する「責任を負う」肯定的な形として提示されることが多いため、完全に非難することは一般的ではありません。しかし同時に、方程式の技術的負債の側面は、コードベースが次第にオープンになり、作業が難しくなることを意味することがよくあります。そして、特に人々が前進し、新しい開発者がその地位に就く必要があるため、技術的な負債（つまり、メンテナンス）コストが高騰し始めます。 ですから、ある意味では、コードの所有権に対する高いレベルのニーズが、一般的なプログラマーの想像力の中で、仕事の匂いとして公然と見られていれば、私たちの職業にとって良いことだと思います。「仕事に責任と誇りを持っている」と見なされるのではなく、「技術的な負債を介して自分自身を定着させ、人工的な職の安全を確保する」と見なすべきです。 そして、テスト（思考実験）は基本的にすべきだと思います：もしその人（あるいはチーム全体）が明日地球の表面から消えたとしたら？これはプロジェクトの巨大な-おそらく致命的な-怪我になりますか、それとも新しい人々を連れて来て、彼らにdoccosとヘルプファイルを読んでもらい、数日間コードを遊んでもらうことができますか？数週間でビジネスを開始します（1か月ほどで完全な生産性に戻ります）。

27 development-process  code-quality  source-code  code-smell  code-ownership 

会社の従業員として、コードを書くとき、添付ファイルがあるように感じますか？コードの所有権があると感じますか？または、他の場所に移動した後に何が起こるかを心配せずに、完全に切り離された状態で書き込みますか？ 編集：私は悪いコードを書いて実行することについて話していません...

26 teamwork  coding  code-ownership 

最近、私の会社では、1人の開発者が1つの機能に集中する（そして1人だけ）ことが推奨されています。それは、開発者を通常のチームルーチンとは別に設定し、他の責任（会議など）から解放するようなものを意味します。この人は、テクノロジに関して「唯一の」責任を負います。 記録のために、SAFe内でSCRUMを使用し、チームごとにフルタイムの開発者がいて、2つのチーム（AndroidとiOS）の間でQAと製品所有者を共有しています。 これは短期的に生産性を高めることに同意しますが、多くの理由でこれは悪い習慣であると感じています（そして大学で学んだと思います）。 コードレビューは価値を失います。 最小限の知識共有。 リスクの増加。 チームの柔軟性の喪失。 私は正しいですか、それとも悪い習慣ではありませんか？

22 agile  team  code-ownership 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 4年前に閉鎖されました。 問題：私はフリーランスのマーケットプレイスに取り組んでおり、クライアントがバックエンドで無限の遅延と多くのバグを抱えて作業することは不可能であるため、クライアントの1人とプロジェクトをキャンセルすることにしました。私は彼に部分的な払い戻しをしたいと思います（私は2か月働いていて、3k行のコードがあるので、彼のバックエンドの問題のためにアプリケーションはまだ動作しませんが）。 質問：私が書いたコードの「所有者」は誰ですか？プロジェクトが開始されたとき、私たちはそれについて同意しませんでした。私のコードを使わないように言ってもいいですか？とにかく、彼は私の禁断を無視できることを理解しています。そう言う正式な「権利」があるかどうかを知りたいだけです。

11 freelancing  code-ownership 

私の4人の経験豊富な開発者のチームは、大規模なモジュール式のWindowsアプリケーション（約200 KLoC）に取り組んでいます。私はプロジェクトの開始時（3年前）からコアコードベースに焦点を当てており、チームマネージャーではありませんが、徐々にセミリードの開発者ポジションに移行しています。 私たちの現在のイテレーションは、コアコードベースへの約15の変更を含む、上級管理職から要求された優先度の高いUI更新です。マネージャーから尋ねられたとき、15の変更のそれぞれが完了するまでに 4時間未満、合計で7営業日未満であると推定しました。それから私はボランティアでその仕事をしました。代わりに、マネージャーは15のタスクすべてを4人の開発者全員に均等に分配することを決定しました。 仕事を始めてから3日間で、次の2つのことがわかりました。 他の経験の浅いチームメンバーは、それぞれ約1つ以下のタスクを完了しました。 実行中のブルックの法則：半分の時間を費やして支援を提供しました（コンポーネントを使用するよう指導することを試みました）。その結果、私は自分で2つだけタスクを完了しましたが、予想された5または6ではありませんでした。 私は遅刻しているのではないかと心配して上司に連絡し、残りのタスクを完了するよう再度提案しました。私の要求は親切に拒否されました。負荷を均等に分割する理由は2つあります。 トラック/バスの要素を制限-これらのスキルで他の開発者を強化し、将来、私だけでなく誰にでもどんな仕事でも与えることができるようにします。 「ボトルネック」（私）を解消し、作業を迅速に行うため。 明確にするために、私は問題はありません：a）時間を教えることに投資する、b）私のコードに触れる人々、またはc）仕事の安全。実際、私は定期的にチームリーダーに、コアコードベースの特定の側面について他の開発者をトレーニングしてリスクを減らすように提案しています。 このイテレーションでは、優先度の高いバグ修正の大規模なコレクションも対象としているため、ワークロードが再分散されれば、より多くの進歩が見込めるようになります。 Mythical-Man-Monthでは、Brooksが提案する「外科チーム」では、すべてのチームがリード+サブリード（マネージャーと私）といくつかのマイナーな役割で構成されています。私たちは自然にこの組織に陥っているように感じますが、私のマネージャーはそれに反対しています。バスファクターはすでに処理されており（マネージャーはコアコードに精通している）、ボトルネックは実際には存在しない（開発者が増えると作業が速くならない）。この点で、外科チームは良いことだと思います。 これらは私の気持ちですが、私は経験豊富なマネージャーではありません。バス要因（木のノック）に対処する必要もありませんでした。ブルックスは正しかったですか？バス要因が関係する「外科チーム」で働いたことはありますか？専門知識の配布を管理するためのより良いテクニックはありますか？ 同様の質問： バス係数を増やすと同時に専門化する方法は？ /software/103718/always-keeping-2-people-expert-on-any-one-chunk-of-code

10 teamwork  code-ownership  brookslaw 

たとえば弱いコード所有権ではなく、スクラム方法論に従って集団的なコード所有権を実践する場合、絶対的な義務はありますか？

9 scrum  code-ownership 

私の会社の一部の開発チームはアジャイル開発手法に切り替えており、開発者の作業は、2週間の反復サイクルのため、些細なソフトウェア機能について細かい点について話し合い、プログラムするために減少しているようです。また、「開発者なら誰でもバグを修正できる」という考え方もある。私は最近、それらのチームの1つに参加し、同じ会社の別のチームから転勤しました... 開発者はソフトウェアの機能を最初（設計）から最後（実装および単体テスト）まで所有する必要があると強く感じます。アジャイルはこの考えに反しているようです。私の認識に真実はありますか、それともアジャイルの悪い実装を生きているだけですか？ 2週間の反復の間、人々は、そのサイクル中のワークロードに応じて、新しい小さな機能とバグ修正をいくらか恣意的に割り当てられます。ソフトウェアの主要な機能の責任を誰も所有していないようです。我々は追加のような、些細なものに倍の愚かな金額を費やす単一などの話、毎日スクラム、コードレビュー、で、2週間の反復中にダイアログに完了ボタンを では、アジャイルプロジェクトでは、より大きな機能をどのように管理するのでしょうか。責任は誰にありますか：個々の開発者またはチーム全体？どのようにしてマニューシャから自分自身を抽出し、より長期的な目標に焦点を当てますか？どんなフィードバックも価値があります。

8 project-management  agile  product-features  code-ownership