プログラマがコードレビューを処理するための最良の方法は何ですか？
私はコードレビューにかなり慣れていませんが、博士号を取得している間は何年もコーディングを行ってきました。
レビュー担当者がコードを変更して1行ずつ確認する場合、同意できない場合はどうしますか？ Xを選択し、レビュアーがそれをYに変更し、Yを念頭に置いていたが、デメリットのためにそれを行わないことにしたが、レビュアーはこれらのデメリットは重要ではないと断言することがある。あなたはあなたの意見の相違を言葉で表現するべきでしょうか、それとも単にそうではなく、それらに耳を傾けるべきでしょうか？
あなたが批判を受け入れるのが得意でない場合、そして査読者が組織のより上級の人である場合、それは困難です。防御的すぎると遭遇するのは良くないでしょう。
確かに、防御的に遭遇しても役に立たない。しかし、どちらも批判されていないので、これが起こっていると感じた場合は、コードレビューが組織内のより良いコードの記述に役立っていないという懸念を表明する必要があります。
レビュー担当者は、実際の非準拠および欠陥についてコードをレビューする責任があり、コードを彼らが行ったようにコードを記述する手段として使用しないでください。つまり、レビューは、あなたが何かをどのように行ったかをレビューし、間違いを犯した（私たちの最高の何か）か、フレームワークや標準、または「歴史的理由」を理解しなかった領域を指摘するコードが書かれていることを意味しますあなたがいる場所です。
したがって、何かを行う方法が複数ある場合は、コードを別の方法に変更する正当な理由が必要です。それ以外の場合は、単純に非構築的なチャーンが役立つわけではありません。
また、レビュアーも完璧ではないことを忘れないでください。彼らはYがそれを行う方法であるという考えを持っているかもしれません、そして、Xがより良いことに気づいていません。方法Xでそれを行った理由を説明する必要があります。レビュー担当者があなたに同意するか、またはYがより良い解決策である理由を彼があなたに説明する可能性があります-彼がそうでないことを知らない他の要因があるかもしれません。
つまり、レビューは、チームメンバーがコードの変更について連絡する方法です。そのため、レビュー担当者に相談してください。
それが役立つ場合は、レビューされているコードの作成者でさえないかのように、公平な方法で話します。結局のところ、コードは会社またはチームに属しており、チームはそれを維持する必要があります。あなたはたまたまそれを書いた人でしたが、それは多くの人が信じているほど重要な要素ではありません。
コンピュータコードの記述は、不確実性の下での意思決定の主な例です。常に相反するプレッシャーがあり、特定の質問でどのように判断するかは、どのようなプレッシャーを認識し、どの程度の大きさであると見なすかによって異なります。
したがって、レビュー担当者があなたの決定に同意しない場合、それは彼らがあなたとは異なるプレッシャー/リスクを見るか、またはそれらのいくつかはあなたよりも大きい/小さいと見なすことを意味します。 絶対にこれらの違いについて話す必要があります。そうしないと、そもそも意見の不一致の原因となった問題が永続するからです。
レビュアーの方が上級者である場合、その経験から、このリスクまたはそのリスクは実際にはあまり重要ではない、またはある種のエラーが組織で発生した長い歴史があることを知っている可能性があるため、特に注意する価値があります。それを避けるために。逆に、レビュアーがおそらく知らないことを知っていると感じた場合は、それを絶対に表現する必要があります。黙っていることはあなたの義務の怠慢に等しい。
状況を処理する上で最も重要な部分は、設計の決定に対する批判は事実上常にnot誰かの人格に対する批判であることを理解することです。 （実際にそうであるまれなケースでは、すぐに気づくでしょう。本当に誰かを満足させることができない場合、何もしなくても違いはないので、ベストプラクティスに従うことの害はどこにありますか？それは、コンピューターコードに含まれる多くのリスクと報酬に対するさまざまな人々の異なる認識の結果であり、現代のコンピューターコードがいかに複雑であるかを考えると、それは予想されることです。違いについて話すことは、コードの改善に役立ちますandこの場合と将来の場合の協力を改善します。
他の回答にはすでに非常に優れた情報が含まれています。 gbjbaanbによってほのめかされているいくつかの側面について少し拡張したいと思います（彼の回答に対する私のコメントを参照してください）。
私の経験では、コードレビュー中にさまざまな種類のフィードバックを観察しました。
- 「これは正直に言って、これは間違っている/最適とは言えず、この方法で変更する必要があると信じています。」私は通常、この種のフィードバックを真剣に受け止めています。提案した変更に反対するのは、それに反対する点があると思う場合だけです。
- 「私はあなたの解決策は大丈夫だと思っています。この代替案を検討してください。しかし、変更を受け入れるかどうかはあなた次第です。」私もこの種のフィードバックを真剣に受け止めています。レビュー担当者は別の方法を提案していますが、彼らのソリューションの方が優れているという強い意見はありません。私は何かを学ぶ機会があり、私はそれが好きなら変更を受け入れます。それ以外の場合は、私の好みに応じてコードを保持しておけば、レビュー担当者は問題ないと判断します。
- 「別の方法で変更したので、期間を変更する必要があります。」、または「ああ、コードを変更したのは...です」という変更も提案されていませんが、すでにコミットされています。変更について簡単に説明します。次のタスクに進む必要があるため、詳細を説明する時間はあまりないというヒントが付いています。
- レビュー担当者は、コードを改善せず、コードを変更する、些細な性質の小さな変更を提案します。提案された変更について議論するように求められると、レビュアーは、疲れ果てて諦めるまで、些細な詳細についての長い議論に入ります。
オプション3、4は1と2に偽装されている可能性があります。「私が提案した方法でそれを行うことが本当に重要でした。」または、「本当に望めば、変更を拒否することができます。」と、実際には言われていることの正反対を意味する口調で言った。不要であると考える変更に反対する場合は、共有コードの所有権を使用して、「コードはあなたのものではなく、チームのものである」という態度を正当化できます。レビュアーが議論に対してあまりオープンではなく、いらいらし、すべてのコストでソリューションをプッシュしようとする場合、レビュアーの意図が正直でない場合は、それを知ることができます。基本的に彼らはすでに決定しており、これ以上の議論は時間の無駄です。
IMOオプション1と2は、正直なレビュー担当者が手助けしようとしていること、自分の仕事を尊重しながら何かを教えようとしていること、そして自分自身で何かを学ぶことに心を開いていることを示しています。このシナリオでは、レビュー担当者から建設的なフィードバックを受け取ったときに、あまり誇りに思わないようにします。
オプション3、4は、いくつかの強力なゲームが進行中であることを示しています。重要なのは、私たちがそれを自分のやり方で行うか、それともあなたのやり方で行うかであり、両方を満たす良い解決策を見つけようとすることではありません。これは、レビュアーのエゴに関連している可能性がありますが、彼らの考え方に従わないコードを理解できないことにも関連している可能性があります。彼らは通常、見慣れないコードに邪魔され、コードベース全体に影響を与えたいと考えています。
状況3と4が頻繁に発生すると、チームの作業が非常に不快になる可能性があります。そのような状況では、チームを離れることを検討します。
あなたが同意しないときに何をすべきかというあなたの問題に取り組むために...
それを話すことは、ほとんどの人がすでに指摘したように私たちが行く方法です。
あなたがすでにそれを行っている場合、おそらく複数回であっても、私たちが使用する有用なテクニックの1つは、いくつかの領域でまだ意見の相違がある場合、「ええ、それをリファクタリングするのは良いことです-
そのために別のチケットを入れることはできますか？
別のチケットを使用すると、私がいくつかの場所でよく知っている恐ろしい「解約して移動しない」モードの代わりに、コードを取得できます。これはアジャイルにうまく適合し、「可能な」最小量を実行し、負荷を分散します。 yagniが適用される場合があります。プロダクトマネージャーは、クライアントへの価値、期限、リソースの観点から、リファクタリングよりも差し迫ったニーズがあると判断する場合があります。
コードレビューはおそらく一般的には良いことですが、私の経験からすると、新しいコーディングガイドラインを使用する新しいチームの開発者や、重要なバグを修正するためのツールとして役立ち、エラーのリスクが軽減されます。レビュアーよりも自分のことをよく知っていると思われる場合は、レビュアーが提案するソリューションの方が優れている理由を尋ね、問題についての洞察を議論する必要があります。誰もがすべてを最もよく知っているわけではないので、コードレビューは両方にとって貴重な学習体験であるはずです。
コードレビューは、レビューアーとコーダーの両方にとって、潜在的な問題をキャッチし、知識を伝える機会の両方です。
コードレビューアとしての責任は、リスクの可能性のある領域、標準的な慣習への不適合、改善、および一般に同じコードの領域に関する単なる別の観点を強調することです。
これは、開発時のコーダーの決定について議論/理解しない限り、コードの変更をもたらすべきではありません。
レビュー担当者が変更を行っている場合、他のユーザーに作業を委任することが困難な場合があります。これは、多くの賢い人が行うのは難しいことです。
コーダーはレビューを受け取ることで、展開時に起こり得る問題から保護され、何か新しいことを学ぶ機会が与えられ、レビュー担当者と知識を共有する機会が与えられます。
年功序列に関係なく、あなたの考え方は一部の人には起こらない解決策を思い付く可能性があるため、レビューは、あなたが正しいと信じるものを実行するだけで輝かせるチャンスになる可能性があります。
コーダーとレビュアーの両方が間違っている可能性があること、および間違っていても問題がないことを受け入れる限り、レビューはチームがソリューションを共同で作業するため、チームを強化するものになります。
あなたのコードはまだレビューされていないようです:-)
コードレビューの目的は、適切な品質のコードを取得し、適切な品質のコードを入手したことを確認することです。経験の浅い開発者のコードをレビューすると、そのコードを使用して、その開発者を苛立たせることを避けながら、より良いコードを書く方法を教えることができます。
レビュー担当者はneverコードを変更する必要があります。彼らはあなたのコードをどのように変更したいかについて多かれ少なかれ強い提案をすることができ、彼らはあなたのコードを受け入れるかどうかを決めることができます。
レビューが正しく行われた場合、またはコードをレビューした場合、コメントはいくつかのコメントになります[〜＃〜] i [〜＃〜]は、そこから学ぶことができるコードを書くか、または無視-これらは私が意見を持っているものであり、あなたは別の意見を持つことが自由です。私の領域では、関数や変数などの適切な命名が重要であると考えられているため、命名を改善するためのいくつかの提案が得られる場合があります。通常、その場合は変更する必要があります（場合によっては、より適切な名前を見つけることによって）。時々私はバグを見つけるでしょう。あなたはそれらを修正します。時々私は自分がバグだと思うものを見つけるでしょう、そして私は間違っています。コードが正しいことを確認するのが難しい場合は、コードをより明確にします。間違えたら、教えてください。
設計が一般的に正しくないと思うなら、これは以前に議論されたはずです。次に、変更に伴う作業量を考慮に入れて、デザインが十分かどうか、または私が間違っていてデザインが優れているかどうかを検討する必要があります。合意に至るはずです。
レビュー担当者とレビュー対象者が同意できない場合は、問題があります。それは、私たちの1人がチームワークを実行できないか、または私たちの1人が優れたデザインと悪いデザイン、またはその両方を区別できないことを意味します。これは必ずしもあなたの責任ではありません。残念ながら、シニアで無知な開発者がいます。それは会社にとってもあなたにとっても問題になります。
それが起こった場合、非常に、非常に懸命に考えてください。根拠のある批判を受け入れることに問題がありますか？その場合は、態度を変える必要があります。レビュー担当者が正しい理由を理解するのに経験が浅いですか？その場合は問題ありません。レビュー担当者を信頼して学びます。あなたはレビュアーよりもよく知っていますか？レビューを受け入れますが、彼の意見について、信頼できる3人目の開発者に質問してください。あなたは自分自身を本当に確信していて正しいことができることを忘れないでください。