同僚が予告なしに不要な改善を行った場合、自分のコードに対して責任を負うにはどうすればよいですか？
私のチームメイトの1人は、ITショップでのあらゆる取引のジャックであり、私は彼の洞察を尊重します。
ただし、ヘッドアップせずに彼が私のコードをレビューすることもあります（彼は私たちのチームリーダーの2番目のコマンドなので、予想されます）。したがって、最終目標を完了する前に彼が私の変更をレビューし、すぐに変更を加えることもあります。
また、3か月以上前の私のコードの一部に不必要な改善を加えている場合もあります。
これはいくつかの理由で私を困らせます：
- 私はいつも間違いを直す機会を与えられているわけではありません
- 彼は混乱しているときに私が達成しようとしていたことを私に尋ねるのに時間をかけていません。それは彼のテストまたは変更に影響を与える可能性があります
- 私はいつも彼のコードが読みやすいとは限らない
- 期限は問題ではなく、彼の現在のワークロードでは、コードの変更を確認する以外にプロジェクトで作業する必要はありません。
とにかく、私が過去に彼に私のコードの所有権を取得できるように変更したい私の仕事に何かを見た場合は投稿を続けてくれるように彼に言ったことがあります（多分私は「欠点」と言ったほうがいいでしょう）、彼は反応しません。
彼に彼の変化を説明してくれるように頼むと、私は攻撃的になるかもしれないと恐れています。
彼はただ静かにしているだけの人ですが、彼の行動は続きます。私はチームなので、彼がコードを変更することを禁止したくありません（私ができるようなものではありません）。
追加された説明：
- 1つの開発ブランチを共有します。いくつかの重要な作業を失うリスクがあるため、すべての変更が1つのタスクを完了するまで待機しません。つまり、変更がビルドされ、何も破壊されないことを確認します。
- 私の懸念は、私のチームメイトが彼の変更の背後にある理由や目的を説明しないことです。私は彼が私の祝福を必要とする必要はないと思いますが、私たちがアプローチに同意しない場合は、長所と短所について話し合い、両者が何が起こっているかを理解したら決定するのが最善だと思いました。
- 必要がない限り経営陣を巻き込まずに個人的な意見の不一致を解決したいので、これについてはまだチームリーダーと話し合っていません。私の懸念は私たちの仕事に対する脅威というよりは個人的な問題のように思われたので、私はチームリードを煩わせないことにしました。私はコードレビュープロセスのアイデアに取り組んでいます-私のペットのおしっこについてそれをすべて作ることなく、より組織化されたコードレビューの利点を促進するのに役立ちます。
ほとんどの開発者は、いつの日かこの立場にいると思います。被害を受けたと感じたすべての開発者が、彼または彼女が先輩になり、後輩によって書かれたコードをクリーンアップすることを余儀なくされたと感じるとき、それがいかに苛立つかを理解してくれることを願っています。
私にとって、この状況での競合の回避は、次の2つのことに帰着します。
礼儀。開発者は、自分のコードについて誰かと話すことで、あなたが興味を持っていることを知ることができ、大人の専門家としてそれについて話し合うことができます。
「コードの所有権」を忘れてください-チームがコードを所有しています。変更を加えたい他の人々は良いことです。上級開発者が「判読不能」またはそれより悪い変更を行った場合は、それらを取り消します。積極的である必要はありません。変更が機能しなかったことを編集者に知らせてください。復帰について話し合うのはこの上ない喜びです。
コードのチームの所有権は素晴らしいものであり、それは両方の方法を削減します。他の誰かのコードで意味をなさないものを見つけた場合は、修正してください。過度に所有的で不十分なコミュニケーションは、有毒な開発環境を作り出す確実な方法です。
あなたとほとんどの回答者は、2人の同僚間のコミュニケーションの問題としてこれに取り組みますが、実際にはそうではないと思います。あなたが説明するものは、他のものよりも恐ろしく壊れたコードレビュープロセスのように聞こえます。
最初に、あなたの同僚が指揮を執っている2番目であり、彼があなたのコードをレビューすることが期待されていると述べました。それは間違っています。定義により、ピアコードレビューは階層的ではなく、欠陥を見つけるだけではありません。また、学習体験（関係者全員）、ソーシャルインタラクションの機会を提供し、コードの共同所有権を構築するための貴重なツールを証明できます。また、時々彼のコードを確認し、彼から学び、彼が間違っている場合は修正する必要があります（誰もそれを正しく毎回行いません）。
さらに、同僚はすぐに変更を加えると述べました。それも間違っていますが、もちろんあなたはすでにそれを知っています。もし彼のガンホーのアプローチが問題でなければ、この質問をしなかっただろう。しかし、私はあなたが間違った場所で解決策を探していると思います。正直に言うと、あなたの同僚は私に少し思い出させてくれます...そして私と同じような状況で私のために働いたのは、明確に定義されたしっかりしたレビュープロセスと素晴らしいツールのセットでした。同僚がコードをレビューするのを止めて、小さな変更がすべて機能しなくなる前に、同僚に立ち止まって話をすることを本当に望んでいません。それはしばらくの間かもしれませんが、すぐに煩わしくなりすぎて、あなたはあなたが始めたところに戻るでしょう、あるいはもっと悪いことに、彼はあなたのコードのレビューをやめるだけです。
ここでの解決策の鍵は、ピアコードレビューツールかもしれません。私は通常、製品の推奨事項を避けますが、コードレビューでは Atlassian's Crucible は本当に命の恩人です。それが行うことは非常に単純に思えるかもしれませんが、それはそれが驚くほど素晴らしいわけではないという意味ではありません。リポジトリに接続して、個々のチェンジセット、ファイル、またはファイルのグループを確認する機会を提供します。コードを変更する必要はありません。代わりに、正しくないと感じるすべてのものにコメントします。また、絶対に他の人のコードを変更する必要がある場合は、変更を説明する変更セットをコメントに残すことができます。詳細については、Crucibleの製品ページの紹介ビデオをご覧ください。 Crucibleの価格は誰もが利用できるわけではありませんが、無料で入手できる多数の査読ツールがあります。私が使って楽しんだ1つは Review Board で、簡単なGoogle検索で他の多くの人を見つけることができると思います。
どのツールを選択しても、プロセスは完全に変わります。立ち止まって、椅子から降りて、他の人に割り込んで、変更について話し合う必要はありません。あなたがする必要があるのは、毎週いくつかの時間を空けてコメントを読むことです（1週間に1回は単なる提案です。あなたのスケジュールと毎日のルーチンを私よりもよく知っています）。さらに重要なことに、コアレビューはデータベースのどこかに保存されており、いつでも取得できます。ウォータークーラーについての短期間での議論ではありません。古いレビューの私のお気に入りの使用例は、新しいチームメンバーをコードベースに紹介するときです。誰かがコードベースを通り抜けて、どこに行き詰まっているのか、意見が異なるのかなどを指摘できるのは、いつでもいいことです。
先に進むと、この同僚のコードが常に読み取り可能であるとは限りません。これにより、コーディング標準の共通セットがないことがわかります。これは悪いことです。繰り返しますが、これは人の問題としてアプローチすることも、プロセスの問題としてアプローチすることもできます。また、後者を強くお勧めします。チームをまとめて、できるだけ早く共通のコーディングスタイルと標準のセットを採用します。開発エコシステムで一般的な一連の標準を選択したか、独自の標準を考案したかは、特に問題ではありません。本当に大事なことは、あなたの標準が一貫していて、あなたがそれらに固執することです。世の中にはたくさんのツールが役立ちますが、それはまったく異なる議論です。はじめに、非常に簡単なことは、コードで何らかのコミットのフックをある種のスタイルフォーマッタで実行することです。好きなようにコードを書き続けることができ、他の誰かに見られる前に、ツールに自動的に「修正」させることができます。
最後に、 コメント で、経営陣は個々の開発ブランチが必要であるとは考えていないと述べています。ええと、「管理ブランチ」ではなく「開発ブランチ」と呼ぶのには理由があります。私の頭の中で形成されている怒りが出る理由がないので、私はここで停止します。
とにかく、ここであなたの同僚が（少し）過ちを犯していることは疑いません。それは私のポイントではありません。私のポイントは、開発プロセス全体にも障害があるということです。これは修正が簡単なことです。適切なツールで武装し、多数の公式および非公式のプロセスを調査し、チームに適したものを選びます。間もなく、「人の問題」のほとんどが存在しなくなることに気付くでしょう。そして、「私たちは小さなチームです。私たちはそのすべてを必要としているわけではありません」という言い訳を生み出す人（自分自身を含む）に耳を傾けないでください。有能な開発者のチームは、1週間足らずで必要なツールをセットアップし、自動化できるすべてのものを自動化し、二度と振り返ることはありません。
PS。 「コードの所有権」は曖昧な用語であり、常に議論されており、人々によって異なることを意味します。 C2 に関するほとんどの異なる（場合によっては反対の）意見の素晴らしいコレクションを見つけることができます。
「あなたのコード」に対して責任を取るにしたいプロセスについてはどうですか？特定の機能を機能させる唯一の責任はありますか？リーダーは「マイケル、あなたに責任をとってほしい...」と言っていましたか？あるいは、特定の機能が壊れるたびに、チームのリーダーと残りのメンバーがあなたに目を向けるという点で、あなたの責任は暗黙のうちにありますか？
いずれにしても、責任がある場合は、コードに対する権限が必要です。次回、他のフェローが一方的に変更を行い、修正のためにリードが戻ってきたとき、リードと一緒に座って、権限と責任を一致させるように依頼する必要があります。
これですべての状況が解決されるわけではありませんが、ソースコードにコメントを追加してみてください。
- コードが完全でない場合、そのようにマークされる可能性があります。
- コードブロックの目的が自己文書化されていない場合は、それを文書化する必要があります。
結局のところ、レモンを吸う時間を無駄にする代わりにレモネードを作るようにしてください。マイケルが言ったように、一般的に、チームメイトはあなたを悪く見せるようにしています。あなたの過ちから学び、それらを将来の改訂に適用してみてください。
彼の変更がマイナスの影響を与えていると思われる場合は、（外交的に）これを表明してください。それが私なら、なぜ特定の変更が行われたのかを尋ね、元の変更を守ることができるかどうかを確認します。あなたの先輩の同僚も人間です。彼が何かを見落としたり、彼が提供しているマイナスの影響に気付いていない可能性は十分にあります。
政治、法学、経済学に関係なく、誰もが暗黙のうちに「独自のコードを所有している」-それは「物事の本質」である-自分の仕事への個人的なつながりを自然に感じる。
同僚があなたが説明した行動に従事していて、ヘッドアップを要求しても応答しない場合、その同僚は不愉快です。控えめに言っても、あなたを弱体化させようとしている可能性があります（最悪...）-します[〜＃〜]しない[〜＃〜]チームプレーヤーのように聞こえます。
優れた同僚はあなたとベースに触れ、コードの問題をあなたに指摘します-それを修正/変更するか、適切に応答します。私が初心者だったときでも、私のメンターはいつも私が間違っていたことを指摘し、理由を説明して（またはmadeさせてくれたことにとても感謝しています）私が修正します。それは私をより優れたプログラマーにして、誰もが恩恵を受けました。そして、それは私が他の人が行った仕事をレビューするときにいつもやってきたことです。次に、あなた（または誰でも）が実際に「すべての取引のジャック」から何かを学び、コードとチームのすべてが、先生を含めてすべて良くなります。
可能であれば、チームリーダーと非公開で話し合います状況の説明に基づいて、優れたチームリーダーがあなたの側-悪いものはしません...明らかにこれには注意が必要です-あなた自身でそれを判断する必要があります。
あなたがコードを書いたら、私はそれをレビューするべきです。
レビュー中にコードを変更した場合、そのコードはレビューしたコードではなく、変更したコードです。したがって、レビューする必要があります。おそらくあなたによって。
誰かが私の変更をレビューせずに変更を加えて新しいコードをコミットした場合、私は（1）未レビューの変更、および（2）コードレビューが真剣に受け取られた場合に発生する可能性のある最悪の罪をコミットしました。
私はあなたが今のところそれを正しい方法で扱っていると思います-しかし、すぐにこの方法でコーディングすることに満足していないかもしれない程度に気を散らす転換点があります。
もし私があなただったら、私はこの人と1対1で迅速に対応することを要求し、私のPoVを落ち着いてしっかりと説明します。コードなどのチームの所有権はすべて問題ありませんが、すべての開発者に彼の仕事を出すのに十分なスペースを与えない限り、間違いを犯して改善することは決して良いコードを構築することにはなりません。これは、後ではなく早く摩擦領域になる可能性があります。
（これがworkplace.stackexchangeにあった場合、まったく異なる答えがあります。コードレビューを行う正しい方法を理解するのは簡単です。これを遵守するように同僚を説得するのははるかに困難です）。