プログラマーがコードレビューを処理する最善の方法は何ですか？

私はコードレビューはかなり新しいですが、博士号を取得している間は何年もコーディングを行ってきました。

レビュアーがコードを変更し、1行ずつコードを検討する場合、同意しない場合はどうしますか？Xを選択し、レビュアーがそれをYに変更し、Yを思い浮かべていたが、デメリットのためにそれを行わないことに決めたことがありますが、レビュアーはこれらのデメリットは重要ではないと断言します。意見の不一致を言葉で表現するべきでしょうか、それともそうではなく、それらに耳を傾けるべきでしょうか？

批判を受け入れるのが苦手で、レビュアーが組織の上級者である場合は困難です。防御的すぎると出くわすのは良くありません。

確かに、守備として出くわすことは役に立たない。しかし、どちらも批判されていないので、これが起こっていると感じたら、コードレビューが組織内でより良いコードを書くのを助けていないという懸念を本当に表明する必要があります。

レビュー担当者は、コードを実際の非準拠および欠陥についてレビューする責任があり、コードを本来の方法で記述する手段として使用するのではありません。これは、レビューがあなたが何かをした方法をレビューするためにそこにあることを意味し、あなたが間違いを犯した（私たちの最高の何か）、またはフレームワークや標準を理解していない領域、またはいくつかのコードが書かれた「歴史的理由」を指摘します方法はあなたがいるところです。

そのため、何かを行う方法が複数ある場合は、コードを別の方法に変更するのに十分な理由が必要です。そうしないと、単に非構成的な解約が助けになりません。

また、レビュアーも完璧ではないことを忘れないでください。彼らは、Yがそれを行う方法であるという考えを持ち、Xの方が優れていることに気付いていないかもしれません。方法Xでそれを行った理由を説明する必要があります。レビュアーはあなたに同意するかもしれませんし、Yがより良い解決策である理由を言うかもしれません-彼がそうすることを知らない他の要因があるかもしれません。

要するに、レビューは、チームメンバーにコードの変更について伝える方法です。そのため、レビュー担当者に相談してください。

役立つ場合は、レビュー対象のコードの作成者でもないかのように、公平に話します。結局、コードは会社またはチームのものであり、チームはそれを維持する必要があります。あなたはたまたまそれを書いた人でした。それは多くの人が信じているほど重要な要素ではありません。

コンピュータコードを書くことは不確実性の下で決定をすることの代表的な例です。常に矛盾するプレッシャーがあります。また、特定の質問でどのように判断するかは、どのプレッシャーを知覚するか、どのくらいプレッシャーを考慮するかによって異なります。

したがって、レビュアーがあなたの決定に同意しない場合、それは彼らがあなたとは異なるプレッシャー/リスクを見るか、またはそれらがあなたよりも大きい/小さいと考えることを意味します。これらの違いについては絶対に話さなければなりません。そうしないと、そもそも意見の相違につながった問題が永続するからです。

レビュアーが上級の場合、経験上、このリスクまたはそのリスクは実際にはあまり関係がないことを正しく伝えられる場合があります。それを避けるために。逆に、レビュアーがおそらく知らないことを知っていると感じたら、絶対にそれを表現しなければなりません。黙っておくことは、あなたの義務の放棄に相当します。

状況を処理する上で最も重要なことは、設計上の決定に対する批判は、常に誰かの性格に対する批判ではないことを理解することです。（実際に存在するまれなケースでは、すぐに気付くでしょう。本当に誰かを喜ばせることができなければ、何も違いはありません。ベストプラクティスに従うことの害はどこにありますか？それは、コンピューターコードに関連する多くのリスクと報酬について異なる認識を持つさまざまな人々の結果であり、現代のコンピューターコードがいかに複雑であるかを考えると、予想されることです。違いについて話すことは、コードを改善し、この場合と将来のケースであなたの協力を改善するのに役立ちます。

他の回答にはすでに非常に良い情報が含まれています。gbjbaanbによって示唆されたいくつかの側面について少し拡張したいと思います（彼の答えに対する私のコメントを参照）。

私の経験では、コードレビュー中にさまざまな種類のフィードバックを観察しました。

1. 「これは間違っている/次善策であり、このように変更する必要があると正直に信じています。」私は通常、この種のフィードバックを真剣に受け止めていますが、それに対して強い点があると思う場合にのみ、提案された変更に反対します。
2. 「解決策は問題ありません。この代替案を検討してください。変更を受け入れるかどうかはあなた次第です。」私もこの種のフィードバックを真剣に受け止めています。レビュアーは、ソリューションが優れているという強い意見を持っていなくても、代替案を提案しています。私は何かを学ぶ機会があります。もしそれがもっと好きなら、変更を受け入れます。それ以外の場合、レビュアーは、自分の好みに応じてコードを保持すれば問題ないと判断します。
3. 「別の方法で行っていたので、変更する必要があります。期間」、または「ああ、コードを変更しました...」という変更は提案されておらず、すでにコミットされています！変更に関するいくつかの簡単な説明がありますが、次のタスクに進む必要があるため、詳細を議論する時間があまりないというヒントがあります。
4. 校閲者は、コードを改善するのではなく、単に変更するだけの些細な変更を提案します。提案された変更について話し合うように求められると、レビューアは、あなたが使い果たしてしまうのをgiveめるまで、些細な詳細についての長い議論に入ります。

オプション3、4は1および2に変装する場合があります。「私が提案した方法で行うことは本当に重要でした。」または「本当に必要な場合は、変更を拒否できます。」と、実際に言われていることの反対を意味する口調で言いました。不要と思われる変更に反対する場合は、共有コードの所有権を使用して、この態度を正当化できます。「コードはあなたのものではなく、チームのものです！」レビュアーが議論に対してあまりオープンでなく、いらいらし、すべてのコストでソリューションをプッシュしようとした場合、レビュアーの意図が正直ではないことを知ることができます。基本的に彼らはすでに決定しており、それ以上の議論は時間の無駄です。

IMOオプション1および2は、支援しようとしている正直なレビュアーのサインであり、あなたの仕事を尊重しながら何かを教えようとしています。このシナリオでは、レビュアーから建設的なフィードバックを受け取っても誇らしくなりすぎないようにしています。

オプション3、4は、何らかのパワーゲームが進行していることを示唆しています。重要なのは、私たちが自分のやり方で行うか、あなたのやり方で行うかであり、両方を満たす満足できる解決策を見つけることではありません。これは、レビュアーのエゴに関係している可能性がありますが、レビュアーの考え方に従っていないコードを理解できないことにも関係しています。彼らは通常、馴染みのないコードに邪魔され、コードベース全体にその方法を課そうとしています。

状況3と4が頻繁に発生する場合、チーム作業は非常に不快になる可能性があります。このような状況では、チームを離れることを検討します。

同意しない場合の対処方法の問題に対処するには...

それを話すことは、ほとんどの人がすでに指摘しているように行く方法です。

すでにそれをしている場合、おそらく複数回、私たちが使用する1つの有用なテクニックは、いくつかの分野でまだ意見の相違がある場合、「はい、それをリファクタリングすることは良いことです-

そのために別のチケットを入れることはできますか？

別のチケットを使用すると、いくつかの場所でよく知られている恐ろしい「解約して移動しない」モードの代わりに、コードを取得できます。これはアジャイルにうまく適合し、「可能な」最小量を実行し、負荷を分散します。時々yagniが適用されることがあります。製品マネージャーは、クライアントへの価値、期限、リソースに関して、リファクタリングよりも差し迫ったニーズがあると判断する場合があります。

コードレビューはおそらく一般的には良いことですが、私の経験からすると、新しいコーディングガイドラインを使用する新しいチームの開発者や重要なバグを修正するためのツールとして最適であり、エラーを起こすリスクが軽減されます。あなたがレビュアーよりもよく知っていると信じている場合、彼または彼女が提案する解決策がなぜ優れているのかを尋ね、問題に関するあなたの洞察と議論する必要があります。誰もがすべてを最もよく知っているわけではないので、コードレビューは両方にとって価値のある学習経験であるべきです。

コードレビューは、レビュー担当者とコーダーの両方にとって、潜在的な問題を発見し、知識を伝える機会です。

コードレビュー担当者としての責任は、リスクの可能性のある領域、標準プラクティスへの不適合、改善、および一般的に同じコード領域に関する別の観点を強調することです。

これにより、開発時のコーダーの決定について議論/理解することなく、コードを変更することはできません。

校閲者が変更を行っている場合、他の人に作業を委任するのが困難になる可能性があります。

レビューを受け取ったコーダーは、展開時に起こりうる問題から保護され、何か新しいことを学ぶ機会が与えられ、レビュー担当者と知識を共有する機会が与えられます。

年功に関係なく、あなたの考え方は、ある人にはまったく起こらない解決策を思い付くことができるので、あなたが正しいと思うことをするだけで、レビューが輝くチャンスになります。

コーダーとレビュアーの両方が間違っている可能性があり、間違っていても構わないことを受け入れている限り、レビューはチームで協力するため、チームを強化するものになります。

コードをまだレビューしていないようです:-)

コードレビューの目標は、適切な品質のコードを取得し、適切な品質のコードを取得したことを確認することです。経験の浅い開発者のコ​​ードをレビューすると、その開発者をいらいらさせずに、より良いコードの書き方を教えるために使用できます。

レビューアはコードを変更しないでください。彼らはあなたのコードをどのように変更したいかを多かれ少なかれ強力な提案をすることができ、あなたのコードを受け入れるかどうかを決めることができます。

レビューが右になった場合、私はあなたのコードを確認した場合/、あなたがそうなりますと、どのようにいくつかのコメントである私はあなたから学ぶことができるコードを書く、あるいは無視するだろう-これらの私は意見を持っているものがあり、あなたが持っていることは自由です異なる意見。私の分野では、関数、変数などの適切な命名が重要であると考えられているため、命名を改善するための提案を得ることができます。通常、その場合は変更を行う必要があります（場合によっては、より適切な名前を見つけることによって）。時々バグを見つけます。それらを修正します。時々、自分がバグだと思うものを見つけますが、間違っています。コードが正しいことを確認するのが難しい場合は、より明確にコードを修正します。私がそれを間違えただけなら、あなたは私に言う。

設計が一般に正しくないと思うなら、これは以前に議論されているはずです。次に、変更にどの程度の作業が関与しているかを考慮して、デザインが十分であるかどうかを検討する必要があります。最終的に合意に達する必要があります。

校閲者と校閲者が同意できない場合、問題があります。なぜなら、私たちのうちの1人はチームワークができない、または私たちのうちの1人は良いデザインと悪いデザイン、またはその両方を区別できないからです。これは必ずしもあなたのせいではありません。残念ながら、上級で無知な開発者がいますが、それは会社にとってもあなたにとっても問題になります。

それが起こった場合、非常に、一生懸命に考えてください：あなたは、根拠のある批判を受け入れることに問題がありますか？その場合は、態度を変える必要があります。レビュアーが正しい理由を見るにはあまりにも経験が浅いですか？その場合は、問題ありません。レビュアーを信頼して学びます。レビュアーよりもよく知っていると確信していますか？レビューを受け入れますが、3番目の信頼できる開発者に意見を聞いてください。あなたは本当に自分自身を確信し、正しいことができることを忘れないでください。しかし、あなたは自分自身を本当に確信し、間違っていることもできます。