同僚が予告なしに不必要な改善を行った場合、どのようにコードに責任を負いますか？

私のチームメイトの1人はITショップのすべての取引のジャックであり、私は彼の洞察を尊重しています。

ただし、彼は時々頭を使わずに私のコードをレビューします（彼はチームリーダーの2番目の指揮官なので、それは予想されています）。そのため、時々、彼は最終目標を完了する前に私の変更をレビューし、すぐに変更を加えます。

また、3か月以上前のコードの一部に不要な改善を加えた場合もあります。

これにはいくつかの理由があります。

1. 間違いを修正する機会が常に与えられるとは限らない
2. 彼は、彼が混乱しているときに私が何を達成しようとしていたかを尋ねる時間をとっていないので、テストや変更に影響を与える可能性があります
3. 彼のコードが読めるとは限らない
4. 期限は問題ではなく、彼の現在のワークロードは、コードの変更を確認する以外に私のプロジェクトでの作業を必要としません。

とにかく、私は過去に彼が私のコードの所有権を取得できるように変更したい何かを私の仕事で見た場合、私に投稿してくださいと言いました（多分私は「欠点」と言うべきでした）、彼は応答しませんでした。

彼に私に彼の変化を説明するように頼むとき、私は攻撃的になるかもしれないと恐れています。

彼は自分を守る静かな人ですが、彼の行動は続きます。私たちはチームであるため、私は彼にコードの変更を禁止したくありません（できませんでしたが）。

説明を追加：

• 1つの開発ブランチを共有しています。重要な作業を失うリスクがあるため、すべての変更が1つのタスクを完了するまで待機しません。したがって、変更を確実にビルドし、何も壊さないようにします。
• 私の懸念は、チームメイトが彼の変更の背後にある理由や目的を説明していないことです。私は彼が私の祝福を必要とするべきではないと思うが、私たちがアプローチに同意しない場合、私たちが長所と短所を議論し、両方が何が起こっているかを理解したら決定を下すことが最善だと思った。
• これはチームリーダーとはまだ話し合っていません。必要でない限り、経営陣が関与することなく個人的な意見の不一致を解決したいからです。私の懸念は私たちの仕事に対する脅威というよりも個人的な問題のように思われたので、チームリーダーを煩わせないことにしました。私は、コードレビュープロセスのアイデアに取り組んでいます。これは、私のペットの気持ちをすべて気にすることなく、より組織的なコードレビューのメリットを促進するためです。

ほとんどの開発者はある時点でこの位置にいると思います。被害を受けたと感じたすべての開発者は、自分がシニアになったときにどれほどイライラするかを理解し、後輩が書いたコードをクリーンアップすることを余儀なくされると思います。

私にとって、この状況での競合を回避することは、次の2つのことです。

1. 礼儀。開発者は自分のコードについて誰かと話をすることで、あなたが興味を持っていることを知り、大人のプロとして議論することができます。

2. 「コードの所有権」は忘れてください-チームがコードを所有しています。変更を行いたい他の人は良いことです。上級開発者が「読めない」またはさらに悪い変更を加えた場合、それらを取り消します。あなたは積極的である必要はありません、編集者に彼/彼女の変更が機能しなかったことを知らせてください。

コードのチーム所有権は素晴らしいことを覚えておいてください、それは両方の方法を削減します。他の人のコードで意味をなさないものを見つけたら、それを修正してください。過度に所有的で不適切なコミュニケーションをとることは、有毒な開発環境を作り出す確実な方法です。

あなたとほとんどの回答者は、2人の同僚間のコミュニケーションの問題としてこれに取り組んでいますが、実際にはそうは思いません。あなたが説明することは、何よりもひどく壊れたコードレビュープロセスのように聞こえます。

まず、同僚が2番目の指揮官であり、同僚があなたのコードをレビューすることを期待していると言います。それはただ間違っています。定義上、ピアコードレビューは階層的ではなく、間違いを見つけるだけではありません。また、（関係するすべての人に）学習体験、社会的相互作用の機会を提供し、集合的なコードの所有権を構築するための貴重なツールを証明できます。また、彼のコードをときどき確認し、彼から学び、彼が間違っているときに修正する必要があります（毎回誰もそれを正しくしません）。

さらに、あなたの同僚がすぐに変更を加えることを言及します。それも間違っていますが、もちろん既に知っています。彼のガンホーアプローチが問題にならなければ、この質問はしなかったでしょう。しかし、間違った場所で解決策を探していると思います。正直に言うと、あなたの同僚は私に少し思い出させてくれました。同じような状況でうまくいったのは、明確に定義された堅実なレビュープロセスと素晴らしいツールのセットでした。同僚があなたのコードをレビューするのを止めたくはありません。そして、小さな変更が実際に機能しない前に、彼に停止してあなたに話をするように頼みます。それはしばらくの間かもしれないが、彼はすぐにそれがただ面倒になり、あなたが始めたところに戻ってくるだろうか、さらに悪いことに彼はあなたのコードのレビューをやめるだろう。

ここでの解決の鍵は、ピアコードレビューツールかもしれません。私は通常、製品の推奨事項を避けますが、コードレビューのためにアトラシアンのクルーシブル本当に命の恩人です。それがすることは非常に単純に思えるかもしれませんが、それは驚くほど素晴らしいというわけではありません。リポジトリに接続し、個々の変更セット、ファイル、またはファイルのグループを確認する機会を提供します。コードを変更することはできませんが、代わりに、まったく気分が悪いと思われるすべてについてコメントします。また、他の人のコードを絶対に変更する必要がある場合は、変更を説明したコメントを変更セットに残すだけです。詳細については、Crucibleの製品ページの紹介ビデオをご覧ください。Crucibleの価格は万人向けではありませんが、無料で利用できる多数のピアレビューツールがあります。私が協力して楽しんだものの1つはレビューボードです。簡単なGoogle検索で他の多くの人を見つけることができると確信しています。

どのツールを選択しても、プロセスは完全に変わります。停止したり、椅子から降りたり、他の人を中断したり、変更について話し合ったりする必要はありません。あなたがする必要があるのは、毎週いくらかの時間を空けてコメントを確認することです（1週間に1回は提案に過ぎません。あなたはあなたのスケジュールと日課を私よりよく知っています）。さらに重要なことは、コアレビューはどこかのデータベースに保存されており、いつでも取得できることです。それらは、ウォータークーラーに関する一時的な議論ではありません。古いレビューの私のお気に入りの使用例は、新しいチームメンバーをコードベースに紹介するときです。私たちが正確に立ち往生している場所や意見の異なる場所などを指摘して、コードベースを新しい人に紹介できるのはいつでもいいことです。

次に、この同僚のコードが常に読めるとは限らないことに言及します。それは、あなたがコーディング標準の共通セットを持っていないことを私に知らせて、それは悪いことです。繰り返しますが、これは人の問題としてアプローチすることも、プロセスの問題としてアプローチすることもできますが、後者を強くお勧めします。チームをまとめ、共通のコーディングスタイルと一連の標準をできるだけ早く採用します。開発エコシステムで一般的な標準のセットを選択した場合でも、独自の標準を考案した場合でも、実際には関係ありません。本当に重要なのは、あなたの標準が一貫していること、そしてあなたがそれらに固執することです。たくさんのツールがありますが、それはまったく別の議論です。始めるためだけに、非常に簡単なことは、プリコミットフックを使用して、コード上で何らかのスタイルフォーマッターを実行することです。好きなようにコードを書き続けることができ、他の人がそれを見る前にツールに自動的に「修正」させることができます。

最後に、管理者は個々の開発ブランチが必要であるとは考えていないことをコメントで述べています。まあ、「管理ブランチ」ではなく「開発ブランチ」と呼ぶ理由があります。頭の中に暴言が出てくる理由はないので、ここでやめます。

そうは言っても、ここにあなたの同僚が（少し）間違っていることを疑わないことを知っています。それは私のポイントではありません、私のポイントは、あなたの開発プロセス全体にも障害があるということです、そしてそれは修正するのがより簡単なものです。適切なツールを使用して、数多くの公式および非公式のプロセスを調査し、チームに合ったものを選択してください。すぐに、ほとんどの「人の問題」がもう存在しないことに気付くようになるでしょう。そして、「私たちは小さなチームです。私たちはすべてを必要としません」という言い訳をする人（あなた自身を含む）に耳を傾けないでください。有能な開発者のチームは、必要なツールを1週間以内にセットアップし、自動化できるすべてのものを自動化できます。

PS。「コードの所有権」は曖昧な用語であり、常に議論されており、人によって異なることを意味します。C2についてのほとんどの異なる（そして時には相反する）意見の素晴らしいコレクションを見つけることができます。

「あなたのコード」に責任を負わせたいプロセスについてはどうですか？特定の機能を動作させ続ける唯一の責任がありますか？リードは「マイケル、あなたに責任を負わせて…」と言いましたか？または、特定の機能が壊れるたびにリードとチームの他のメンバーがあなたを見るという点で、あなたの責任は暗黙的ですか？

いずれにせよ、責任がある場合は、コードに対する権限が必要です。次に他のフェローが一方的な変更を行い、リードがあなたに戻ってそれらを修正するとき、あなたはリードと一緒に座って、あなたの権限と責任を調整してもらうように依頼する必要があります。

これで状況全体が解決されるわけではありませんが、ソースコードにコメントを追加してみてください。

1. コードが完全でない場合、そのようにマークされる可能性があります。
2. コードブロックの目的が自己文書化ではない場合は、文書化する必要があります。

結局のところ、レモンを吸う時間を無駄にする代わりにレモネードを作ってみてください。マイケルが言ったように、一般的に、チームメイトはあなたを悪く見せようとはしていません。間違いから学び、それらを将来の改訂版に適用してみてください。

彼の変更がマイナスの影響を及ぼしていると思われる場合は、これを（外交的に）表明してください。私なら、特定の変更が行われた理由を尋ね、元の変更を防御できるかどうかを確認します。あなたの先輩も人間です。彼が何かを逃したか、彼が提供しているマイナスの影響に気付いていない可能性があります。

政治、法律、または経済学に関係なく、誰もが暗黙的に「独自のコードを所有」します。

あなたの同僚があなたが説明した行動に従事していて、あなたがヘッズアップを要求したときに無反応のままである場合、その同僚は控えめに言っても落胆し、あなたを弱体化しようとしている可能性があります（最悪の事態を言います）。 。）- チームプレーヤーのようには聞こえません。

良い同僚はあなたとベースをタッチし、あなたのコードに問題があることを指摘しますあなたに -あなたは/修正し、それを変更したり、適切に対応しましょう。私は初心者のときでさえ、私の指導者はいつも私が間違っていたことを指摘し、その理由を説明し、それを修正させた（または作らせた）ことにとても感謝しています。それは私をより良いプログラマにし、誰もが利益を得ました。そして、それは私が他の人によって行われた仕事をレビューするときにいつもしてきたことです。次に、あなた（または誰でも）が実際に「すべての取引のジャック」から何かを学び、教師を含め、コードとチームがすべて良くなります：教えることは理解を助けます。

可能な場合は、チームリーダーとプライベートに話し合います。状況の説明に基づいて、優れたチームリーダーがあなたの味方になります-悪いチームリーダーはそうしません。明らかに、これには注意が必要です。

コードを作成する場合は、確認する必要があります。

レビュー中にコードを変更した場合、そのコードはレビューしたコードではなく、変更したコードになります。したがって、レビューする必要があります。おそらくあなたによって。

誰かが私の変更をレビューせずに新しいコードを変更でコミットすると、（1）レビューされていない変更、および（2）コードレビューが真剣に取られた場合の最悪の罪をコミットしました。

今のところそれを正しい方法で処理していると思います-しかし、すぐにこの方法でコーディングするのが不愉快な程度に気が散る転換点が来るでしょう。

もし私があなただったら、私はこの人との迅速な一対一を要求し、落ち着いてまだしっかりと私のPoVを説明するでしょう。コードなどのチームの所有権はすべて問題ありませんが、すべての開発者が作業を行うのに十分なスペースを与え、間違いを犯し、改善しない限り、良いコードを構築することはできません。これは、後よりも早く摩擦領域になります。

（workplace.stackexchangeの場合、まったく異なる答えがあります。コードレビューを行う正しい方法を見つけるのは簡単です。同僚にこれに従うよう説得するのは非常に困難です）。