ありそうもないEdgeケースに関するコードレビューでの不一致をどのように処理しますか？
パスカバレッジチームのロボット工学のスタートアップで働いていて、プルリクエストを送信した後、コードがレビューされます。
チームに1年以上在籍している私のチームメイトは、必要以上に多くの作業を行うことを提案するコメントをコードに加えました。いいえ、私は怠惰な開発者ではありません。優れたコメント、変数名、インデントがあり、ケースを適切に処理するエレガントなコードが大好きです。しかし、彼は私が同意しない別のタイプの組織を念頭に置いています。
例を挙げましょう。
私は1日を費やして、自分が作成した遷移検出アルゴリズムを変更するためのテストケースを作成しました。彼は、私が起こる可能性が非常に低いあいまいなケースを処理することを提案していました-実際、それが発生する可能性すらあるかどうかはわかりません。私が作成したコードは、元のすべてのテストケースと私が見つけたいくつかの新しいテストケースで既に機能しています。私が作成したコードは、毎晩実行される300以上のシミュレーションに合格しています。ただし、このあいまいなケースを処理するには、13時間かかります。これは、ロボットのパフォーマンスを向上させるために費やす方がよいでしょう。明確にするために、これまで使用していた以前のアルゴリズムもこのあいまいなケースを処理しませんでした。生成された4万回のレポートでは、一度も発生していません。私たちはスタートアップであり、製品を開発する必要があります。
私はこれまでにコードレビューを行ったことがなく、あまりにも議論の余地があるかどうかはわかりません。私はただ静かにして彼の言うことをするべきですか？時間を上手に使うことに同意できないにもかかわらず、頭を下げて変更を加えることにしました。
私は同僚を尊重し、彼を知的なプログラマーとして認めています。私はある点で彼に同意しないだけで、コードレビューで不一致を処理する方法がわかりません。
私が選択した答えは、ジュニア開発者がコードレビューで不一致に対処する方法を説明するこの基準を満たしていると感じています。
発生する可能性が非常に低いあいまいなケース-実際に発生する可能性さえあるかどうかはわかりません
コードにテストされていない動作がないことは非常に重要です。コードの一部が実行された場合。 1秒に50回、100万分の1の確率で約5.5時間のランタイムが発生します。 （あなたの場合、オッズは低いようです。）
優先順位については、マネージャー（または、担当するユニットの上級管理者）と話し合うことができます。たとえば、コードのパフォーマンスや防弾性のあるコードに取り組むことは最優先事項であり、そのコーナーケースがどれほどありそうもないことです。レビューアは、優先順位について歪んだ考えを持っている場合もあります。担当者と話をすることで、レビュアーの提案に同意（同意）しやすくなり、参照する必要があります。
常に複数のレビュー担当者がいることをお勧めします。コードを1人の同僚だけがレビューする場合は、そのコードを知っている誰か、またはコードベース全般を調べてもらいます。再度、セカンドオピニオンは、レビュアーの提案に、より簡単に（反対）同意するのに役立ちます。
いくつかのコードレビュー中に何度も繰り返しコメントが出ることは、通常、より大きなことが明確に伝えられていないことを示しており、同じ問題が何度も繰り返されています。その大きなことを見つけて、レビュー担当者と直接話し合ってください。十分な質問なぜ質問。コードレビューの練習を始めたとき、それは私に大いに役立ちました。
災害を引き起こした、二度と起こらないはずのコーナーケースの例を挙げましょう。
Ariane 4 が開発されているとき、側面の accelerometers からの値は、 16ビットにフィットするようにスケーリングされました符号付き整数 であり、加速度計の最大出力がスケーリングされた場合neverが32767を超え、最小値が最大になる可能性があるため- never -32768を下回る「範囲チェックのオーバーヘッドは不要」でした。一般に、すべての入力は変換前に範囲チェックされることになっていますが、この場合、それは不可能なコーナーケースをキャッチしようとしています。
数年後、 Ariane 5 が開発され、横方向加速度計をスケーリングするためのコードは、「使用実績がある」ため、最小限のテストで再利用されました。残念ながら、大きなロケットは大きな横加速度を期待できるため、加速度計がアップグレードされ、大きな64ビット float値が生成される可能性があります。
これらのより大きな値は、変換コードで「ラップ」され、no範囲チェック、および 1996年の最初の起動時の結果を記憶します 良くなかった。それは会社に数百万ドルの費用をかけ、プログラムに大きな中断を引き起こしました。
never発生する、extremely発生する可能性が低いなどのように、テストケースを無視してはいけないということです。彼らがコーディングしていた標準は、all外部入力値の範囲チェックを要求しました。それがテストされ、処理されていた場合、災害は回避された可能性があります。
注 Ariane 4ではこれはバグではありませんでした、（すべての可能な値に対してすべてがうまく機能したため）-これは標準に従うことができなかったためです。コードが別のシナリオで再利用された場合、コードは壊滅的に失敗しましたが、値の範囲が切り取られた場合、それはおそらく正常に失敗し、このためのテストケースの存在might 値の確認をトリガーしました。注目に値するのは、コーダーとテスターが爆発後に調査官からいくつかの批判を受けたにもかかわらず、経営陣、QA、およびリーダーシップに過半数の責任が残されたことです。
明確化
すべてのソフトウェアが安全上重要であるとは限らず、失敗してもそれほど壮観ではありませんが、私の意図は、「不可能な」テストがまだ価値を持つ可能性があることを強調することでした。これは私が知っている最も劇的なケースですが、ロボット工学もいくつかの悲惨な結果を生み出す可能性があります。
個人的には、誰かがテストチームにコーナーケースを強調したら、それをチェックするためのテストを実施する必要があります。実装チームリーダーまたはプロジェクトマネージャーmay検出された障害に対処しないことを決定しますが、欠点が存在することを認識しておく必要があります。または、テストが複雑すぎたり、費用がかかりすぎて実装できない場合は、使用中のトラッカーやリスクレジスターで問題を発生させて、これがテストされていないケースであることを明確にすることができます。使用を変更する前、または不適切な使用を防止するため。
以前は処理されていなかったため、あなたの努力の範囲外です。あなたまたはあなたの同僚は、このケースをカバーするために努力する価値があるかどうかあなたの上司に尋ねることができます。
複雑なアルゴリズムでは、現実の世界で発生するすべてのテストケースについて考えたことを証明することは非常に困難です。現実の世界では出てこないため、意図的にテストケースを壊したままにしておくと、まだ考えていないotherテストケースが壊れたままになる可能性があります。
頻繁に発生するもう1つの影響は、追加のテストケースを処理すると、アルゴリズムが必然的により一般的になることです。そのため、allテストケースでアルゴリズムを簡略化してより堅牢にする方法が見つかります。これにより、メンテナンスとトラブルシューティングの時間を節約できます。
また、「これは発生してはならない」バグが実際に発生しているケースが多数あります。これは、アルゴリズムは変更されない可能性がありますが、この1つの未処理のユースケースについて誰も覚えていない場合、その入力は何年も後に変更される可能性があるためです。そのため、経験豊富な開発者は、心の中で新鮮なときにこのようなことを扱います。そうしないと、後であなたを噛むようになります。
これは技術的な問題ではなく、ビジネス戦略の決定です。提案された修正はほとんどが発生しない非常にあいまいなケースに対するものであることに気づきました。ここでは、おもちゃをプログラミングしている場合や、たとえば医療機器や武装したドローンなどをプログラミングしている場合に、大きな違いが生まれます。まれな誤動作の結果は非常に異なります。
コードレビューを行うときは、まれなケースの処理にどれだけ投資するかを決定するときに、ビジネスの優先順位の基本的な理解を適用する必要があります。ビジネスの優先順位の解釈で同僚と意見が合わない場合は、ビジネスの面で誰かと話し合いたいと思うかもしれません。
コードレビューは、コードの正確さについてのみではありません。実際には、それは利点のリストのかなり遠いところにあり、知識の共有の背後にあり、チームスタイル/設計のコンセンサスを作成するためのゆっくりではありますが着実なプロセスです。
あなたが経験しているように、「正しい」と見なされるものはしばしば議論の余地があり、誰もがそれが何であるかについて独自の角度を持っています。私の経験では、限られた時間と注意でコードレビューの一貫性が失われる可能性もあります。同じ問題が、別の開発者によって、または同じ開発者によって別のタイミングで取り上げられるかどうかに関係なく発生する可能性があります。 「このコードを改善するものは何か」という考え方のレビュアー。彼らが自然に自分の努力に追加しない変更を提案することがよくあります。
経験豊富なコーダー（開発者として15年以上）として、私よりも経験年数が少ないコーダーにレビューされることがよくあります。時々彼らは私に穏やかに同意しない、または重要ではないと思う変更を要求します。しかし、私はまだそれらの変更を行います。最終的な結果が製品に弱点をもたらす、時間コストが非常に高い、または「正しい」視点を客観的にすることができる（たとえば、変更が要求される）場合にのみ、変更をめぐって戦います。 t私たちが使用している言語で機能するか、またはベンチマークが主張されたパフォーマンスの向上は1ではないことを示している）。
だから私はあなたの戦いを注意深く選ぶことを勧めます。必要ないと思われるテストケースを2日間コーディングしても、戦うための時間や労力を費やす価値はないでしょう。 GitHubプルリクエストなどのレビューツールを使用している場合は、反対意見を指摘するために、コストやメリットについてコメントすることもできますが、引き続き作業を行うことに同意してください。これは穏やかなプッシュバックとしてカウントされるため、レビューアは境界に達していることを認識し、さらに重要なのは、このようなケースがデッドロックに陥った場合にエスカレートできるように、根拠を含めます。書面による意見の不一致がエスカレートしないようにしたい-仕事の違いについてインターネットフォーラムスタイルの議論をしたくない-そのため、最初から問題について話し、ディスカッションの結果の公正な要約を記録しておくと役立つ場合があります。それでも、作業の必要性について同意しないことに同意します（とにかく、短い友好的ディスカッションで両方について決定します）。
イベント後、これはスプリントのレビューや開発チームの計画会議などに適したトピックです。できるだけ中立的にプレゼンテーションしてください。 「コードレビューで、開発者Aはこの追加のテストケースを特定しました。書くのにさらに2日かかりました。チームは、追加費用がこのコストで正当化されたと思いますか？」 -このアプローチは、あなたがポジティブな光の中であなたを示すので、あなたが実際に仕事をする場合、はるかにうまく機能します。作業が完了し、リスク回避と機能開発のどちらかについてチームを調査したいだけです。
少なくともあいまいなケースには反対することをお勧めします。そうすれば、将来の開発者は、あなたが積極的に訴訟に反対することを知っているだけでなく、適切な障害処理が行われているはずであり、それはすでに整っているはずです。
次に、その失敗を主張するテストケースを作成します。このようにして、動作はより適切に文書化され、単体テストで表示されます。
この答えは明らかに、「可能であるとしても極めて可能性が低い」というあなたの判断は正しいと私たちは判断できないことを前提としています。しかし、そうであり、同僚が同意する場合、イベントに対する明示的なアサーションは、両方にとって満足のいく解決策になるはずです。
あなたはそこに初めているように見えるので、あなたができることはただ1つだけです。チームリーダー（またはプロジェクトリーダー）に確認してください。 13時間はビジネス上の決定です。一部の企業/チームにとっては、多くのことです。一部には、何も。それはまだあなたの決定ではありません。
リードが「そのケースをカバーする」と言っている場合は問題ありません。彼が「いや、それをねじ込む」と言った場合、罰金-彼の決定、彼の責任。
コードレビュー全般については、リラックスしてください。タスクが1度または2度返されることは完全に正常です。
@SteveBarnesの回答で取り上げられていたものの、現物で対処されたとは思えないことの1つ：
失敗の影響は何ですか？
一部のフィールドでは、失敗はWebページのエラーです。 PCのブルースクリーンと再起動。
他の分野では生か死か-自動運転の車がロックする。医療用ペースメーカーが機能しなくなります。またはスティーブの答えで：ものが爆発し、数百万ドルの損失が発生します。
これらの両極端にはworldの違いがあります。
「失敗」をカバーするための13時間が最終的に価値があるかどうかは、あなた次第ではありません。それは経営者と所有者次第である必要があります。彼らは全体像を把握する必要があります。
何に価値があるのかを正確に推測できるはずです。あなたのロボットは単に減速するか、停止しますか？パフォーマンスの低下？または、ロボットの故障は金銭的損害を引き起こしますか？命の喪失？
その質問への答えは、「会社の時間の13時間の価値があるのか」という答えを駆り立てるものです。通知：私は会社の時間を言いました。彼らは手形を支払い、最終的にそれの価値があるものを決定します。あなたの経営陣はどちらにせよ最終決定権を持つべきです。
仕事の優先順位付けを担当する人と話をするかもしれませんか？スタートアップでは、CTOまたは製品の所有者である可能性があります。この追加の作業が必要かどうか、およびその理由を見つけるのに役立ちます。また、あなたは（あなたがそれらを持っている場合）毎日のスタンドアップの間にあなたの心配をもたらすことができます。
平面作業について明確な責任（製品の所有者など）がない場合は、周囲の人と話し合うようにしてください。後で、誰もが製品を反対方向に押していることが問題になる可能性があります。
不一致を処理する最善の方法は、あなたがジュニア開発者かシニア開発者か、あるいはCEOであるかに関係なく、同じです。
コロンボを見たことがなければ、それはかなり素晴らしいショーでした。コロンボはこの非常に控えめな性格でした-ほとんどの人は彼が少し気が狂っていて心配する価値がないと思っていました。しかし、登場控えめで、人々に彼の男を手に入れることができたと説明するように頼むだけで。
Socratic method にも関連していると思います。
一般的に、自分や他の人に質問して、正しい選択をしていることを確認したいとします。 「私は正しい、あなたは間違っている」という立場からではなく、正直な発見という立場から。または、少なくともできる限りベスト。
あなたの場合、ここには2つのアイデアがありますが、基本的に同じ目的があります。それは、コードを改善することです。
他の機能の開発を支持して、ありそうもない（不可能？）ケースのコードカバレッジをスキップすることが、そのための最良の方法であるという印象を受けています。
同僚は、コーナーケースについてより注意するほうが価値があるという印象を受けています。
あなたが見ないことを彼らは何と見ていますか？彼らが見えないのは何だと思いますか？ジュニア開発者として、あなたは自然に質問をする必要があるため、実際には素晴らしい立場にいます。別の回答で、誰かが意外にコーナーケースである可能性が高いと述べています。それで、「理解してください-私はX、Y、Zの印象を受けました-何が欠けているのですか？ウィジェットがframboozleになるのはなぜですか？私はそれが群集の状況下で細かく動くだろうという印象を受けました。スウィズルスティックは実際にANZAブラシを汚しますか？」
あなたの仮定とあなたの発見に疑問を投げかけると、あなたは掘り下げ、バイアスを明らかにし、そして最終的に正しい行動方針が何であるかを理解します。
チームの全員が完全に合理的であり、彼らはあなたと同じようにチームと製品の最善の利益を念頭に置いているという前提から始めます。彼らが意味のないことをしている場合は、彼らが何をしているのかわからない、または何をしていないのかを理解する必要があります。
13時間はそれほど大したことではありません。あなたはそれのために支払われていることを忘れないでください。 「仕事の安全」としてそれを白紙にしてください。また、チーム間で良いカルマを保つことが最善です。これが1週間以上かかるような場合は、上司を巻き込んで、それがあなたの時間の最善の利用法であるかどうか、特に同意しない場合は彼に尋ねることができます。
しかし、あなたはあなたのグループでレバレッジが必要であるように聞こえます。レバレッジを得る方法は次のとおりです。許しを求めて許可を求めないでください。必要に応じて（コースの範囲内、つまり上司が求める問題を完全に解決できることを確認して）プログラムに内容を追加し、事実を上司または同僚に伝えます。 「機能Xを追加しても大丈夫ですか」と尋ねないでください。むしろ、個人的にプログラムに必要な機能を追加するだけです。新しい機能に不満を感じたり、同意しない場合は、削除してください。彼らがそれを好めばそれを保ちなさい。
さらに、彼らがあなたに何かをするように頼むときはいつでも、「余分なマイル」に行き、彼らが言及するのを忘れていたもの、または彼らが言ったことよりうまく機能することをたくさん追加します。しかし、もう1マイル進んでも「大丈夫」かどうかを尋ねないでください。ただそれをし、それが終わった後に気軽にそれについて彼らに伝えてください。あなたがしていることはそれらを訓練することです。
何が起こるかは、あなたのマネージャーがあなたを「やり手」として釘付けにし、彼にあなたの信頼を置き始めるでしょう、そしてあなたの同僚はあなたがあなたがプログラムを所有し始めているBCのリーダーとしてあなたを見始めます。そして、あなたが言及するようなことが将来起こるとき、あなたは本質的にチームのスターであり、チームメイトが同意しないとチームメイトが後退するので、もっと言うべきでしょう。
コードは常により良い場合があります。
コードレビューを行っていて、バグをキャッチするためのより良いものや単体テストが見つからない場合、それは完璧なコードではなく、レビュー担当者が仕事をしていません。改善について言及することを選択したかどうかは個人的な選択です。しかし、ほとんどの場合、チームがコードレビューを行うときは、誰かが気づいたことで改善されたり、全員が時間を無駄にしたりする可能性があります。
とはいえ、コメントに基づいて行動するかどうかは、チーム次第です。変更によって問題が修正されるか、変更なしで十分な付加価値があり、チームがそれらを受け入れる場合は、それらをマージして、後で対処するためにバックログにコメントを記録します。 teamで変更が見つかり、値よりもリスクや複雑さが増す場合は、それに応じて問題を解決する必要があります。
anyコードには、テストでき、少なくとももう1つのリファクタリングを使用できるEdgeケースが少なくとも1つあることを覚えておいてください。このため、コードレビューは、全員が同じコードを同時に見ているグループとして行うのが最善です。最後に、レビュー中のコードが（そのまま）受け入れ可能かどうかについてコンセンサスを得て、コミュニティベースにマージするのに十分な値を追加するか、マージするのに十分な値がある前に特定の作業を行う必要があるかどうか。
あなたがこの質問をしているので、私はあなたが実際に「コードレビュー」をしているのではなく、プルリクエストまたは他の送信メカニズムを作成して、他の人が非決定的な方法でコメントできるようにします。これで、管理の問題と完了の定義に取り掛かります。あなたの管理は優柔不断で、コードレビューのプロセスと目的を実際に理解しておらず、おそらく「完了の定義」（DOD）を持っていないと思います。もし彼らがそうしたなら、あなたの国防総省はこの質問に明確に答え、あなたはここに来て尋ねられる必要がないでしょうから。
どのように修正しますか？まあ、あなたにマネージャーにあなたに国防総省を与えるように頼み、あなたが常にすべてのコメントを実装する必要があるかどうかを教えてください。問題の人物が上司である場合、答えは自明です。
コードレビューにはいくつかの目的があります。あなたが明らかに気づいているのは、「このコードは目的に合っていますか？」つまり、機能的に正しいですか。適切にテストされていますか？非自明な部分が適切にコメントされている;プロジェクトの規則に準拠していますか？
コードレビューのもう1つの部分は、システムに関する知識の共有です。変更されたコードとそれがシステムの他の部分とどのように相互作用するかについて、作成者とレビュー担当者の両方が学ぶ機会です。
3番目の側面は、変更が行われる前に存在していた問題のレビューを提供できることです。かなり頻繁に、他の誰かの変更をレビューするとき、私は以前の反復で見逃したものを見つけるでしょう（かなり頻繁に私自身のものです）。 「これは、これを以前よりも堅牢にする機会です」などの文言は批判ではありません。
私の現在のチームは、コードレビューを、コードがコミット前に無傷で通過する必要があるゲートウェイまたはハードルとしてだけでなく、主にある程度構造化されたディスカッションの機会と見なしています。機能の特定の領域の。情報共有の最も生産的な機会の1つです。 （そして、それが常に同じレビュアーというよりはむしろ、チームの周りでレビュを共有する良い理由です）。
コードレビューを対立的な活動として認識した場合、それは自己実現的な予言です。代わりにそれらをあなたの仕事の最も協調的な部分と見なすと、それらはあなたの製品とあなたが一緒に働く方法への継続的な改善を刺激します。レビューが提案の相対的な優先順位について明確にできる場合に役立ちます。たとえば、「ここに役立つコメントをお願いします」と「xが否定的である場合、これはうまくいきません」の間に1マイルの違いがあります。 。
上記の一般的な説明の多くを行った後、それはあなたの特定の状況にどのように当てはまりますか？私のアドバイスが、オープンな質問でレビューに返信すること、そしてどのアプローチが最も価値があるかnegotiateすることであることが今や明白であることを願っています。追加のテストが提案されている例の場合、「はい、それをテストできます。実装するのに<time>かかると推定します。テストの必要がないことを保証するために他にできることはありますか？」
私があなたの質問を読んだときに私を襲う1つのこと：新しいテストケースを書くのに2日間の努力が必要な場合、どちらの新しいテストも既存のテストとは非常に異なるシナリオです（この場合、おそらく多くの値）または、テストスイートでのコードの再利用を改善する必要性を認識しました。
最後に、コードレビューの値に関する一般的なコメントとして（および上記で述べたことの簡潔な要約として）、このステートメントが好きです Maintainers Do n't ScaleDaniel Vetterによる ：
少なくとも私にとって、レビューとはコードの品質を確保することだけではなく、知識を広め理解を深めることでもあります。最初は、おそらくコードを理解している1人の人、つまり作者（そしてそれは与えられていません）がいます。十分に検討した後、コーナーケースを含めて、それを完全に理解している人が少なくとも2人いるはずです。
この質問は、防御的プログラミングの長所、コーナーケースの危険性、または物理製品のバグによる壊滅的なリスクについてではありません。実際、それはソフトウェアエンジニアリングについてさえまったく考えていませんです。
それが本当に何であるかは、ジュニアがそれを同意したり感謝したりできないときに、ジュニアプラクティショナーがシニアプラクティショナーからの指示をどのように処理するかです。
ジュニア開発者であることについて感謝する必要のあることが2つあります。第一に、それは可能である一方で、あなたが正しいことと、彼が間違っていることを意味しますが、それは確率のバランス上-ありそうもないことです。あなたの同僚があなたの価値を見ることができないという提案をしている場合、あなたはそれを理解するだけの十分な経験がないという可能性を真剣に楽しまなければなりません。この投稿ではその意味がわかりません。
感謝すべき2番目のことは、あなたのシニアパートナーがより責任があるため、いわゆるパートナーであるということです。ジュニアが重要な何かを壊したとしても、彼らが指示に従えば問題はないでしょう。ただし、シニア許可彼らがそれを破る場合、たとえば、コードレビューで問題を提起しないことによって、彼らは当然のことながら多くの問題を抱えているでしょう。
結局のところ、彼らがプロジェクトを主導するためにビジネストラストからの指示を観察することは、あなたの仕事の暗黙の要件です。経験を評価する正当な理由がある場合、一般的に高齢者に任せることはできませんか？あなたは理解できない指示に従わないつもりですか？自分が納得するまで世界は止まるべきだと思いますか？これらの値は、チームでの作業と互換性がありません。
最後のポイント。 6か月前に書いたプロジェクトを思い出してください。大学で書いたプロジェクトについて考えてみてください。すべてのバグと逆さまのデザイン、死角、見当違いの抽象化が今、どれほどひどいように見えるか？ 6か月後には、今日行っている仕事とまったく同じ欠陥を数えると言ったらどうでしょうか。これは、現在のアプローチに盲点がいくつあるかを示すのに役立ちますか？それは経験が生み出す違いだからです。
必要以上に多くの作業を行うことを提案するコードに常にコメントを付けます。
あなたは推奨事項を与えることができますが、最終的に何が必要かを決定するのはあなたの役割ではありません。管理者（またはこの場合はレビュー担当者）が必要と判断したものを実装するのはあなたの仕事です。必要以上のことや強くしすぎることに同意しない場合は、仕事から抜け出す可能性があります。したがって、これに同意し、それと平和になることは、あなたのプロ意識の一部です。
彼が私に起こる可能性が極めて低いあいまいなケースを処理することを提案していた
バグではないもの（つまり、失敗しないと思われるものever）であっても、いかに再処理する必要があるかを示す他の素晴らしい答えがあります。 （たとえば、製品の将来の安全性、標準などに従って構築する場合）優れた開発者の役割の一部は、コードが考えられるすべての状況でいつでも将来も堅牢であるということをできる限り信頼することです-証明済みほとんどの場合、現在の条件下でテストされた状況で動作するだけではありません
コードレビューのビジネス上の有用性を高めるためのコードレビューアへの提案（OPとしてこのような変更を提案する必要があります）：
タイプ別にコメントをマークダウンします。 「重要」/「必須」/「オプション」/「推奨される改善」/「ありがたい」/「困っています」。
これがCDO /肛門/複雑すぎると思われる場合は、少なくとも2つのレベルを使用します。「レビューに合格し、変更をマージできるようにする必要があります」/「その他すべて」。
重要ではないと思われるコードレビューの提案を処理するための提案：
選択したチケットシステムでオープンチケットを作成します（チームが1つを使用することをお勧めします）。提案を追跡します。
Fisheyeやメールレビューのようなコメントへの応答がプロセスで許可されている場合は、チケット＃をコードレビュー項目への応答コメントとして配置します。
レビューアに連絡して、そのアイテムが「修正する必要があるか、マージ/リリースされない」タイプかどうかを明示的に尋ねます。
- 答えが「はい」であるが同意しない場合は、プロジェクト管理の責任者（PM、マネージャーなど）が決定を下します-完全に正直に意見の相違を提示します。これは、あなたがどちらが「正しい」かということではなく、プロジェクトにとって何が良いかということなので、PM /マネージャーの仕事です。
ここで、そのチケットを他の開発リクエストとして扱います。
エスカレーション後に緊急であると判断された場合は、緊急の開発リクエストとして扱います。他の作業の優先順位を下げ、これに取り組みます。
それ以外の場合は、割り当てられた優先度とROI（他の回答で説明されているように、ビジネスラインによって異なる場合があります）に従って作業します。
エスカレートしないこれを経営陣に伝えてください。
ほとんどの企業では、管理担当者は常に、余分なテストを記述せず、コード品質をわずかに向上させるために時間を費やさないようにし、無駄な時間リファクタリング。
多くの場合、コードの品質は、開発チームの未記述のルールと、プログラマーが行った余分な労力に依存します。
あなたはジュニア開発者であり、これは最初のコードレビューですです。あなたはアドバイスを受け入れ、仕事をしなければなりません。チームのワークフローとルールを改善するには、まずそれらを理解し、しばらくの間尊重して、それらがそこにある理由を理解できるようにする必要があります。そうでなければ、あなたはルールを尊重せず、チームの唯一のオオカミになる新しい人になるでしょう。
あなたはチームに不慣れで、しばらくの間得られるアドバイスに従い、彼らがそこにいる理由を見つけ、スクラムミーティングで最初に疑問に思うアドバイスを持ち込まないでください。実際のビジネスの優先事項は、しばらく尋ねることなく明らかになります（そして、管理者が面と向かって言うことではないかもしれません）。
リード/管理要求を満たすコードを作成することが非常に重要です。その他の詳細は、単に「持っているのがいい」です。あなたがその分野の専門家である場合（「ジュニア開発者でない場合」をお読みください）、リーダーに毎回相談することなく、途中で見つけた軽微な問題に対処することができます。
あなたが何かが間違っていると思い、あなたがその分野の比較的専門家であるなら、チャンスはあなたが正しいです。
ここにあなたに役立つかもしれないいくつかのステートメントがあります：
- Xを行うように要求されましたが、コードレビューアはYも行うことを提案しています。それを行うべきですか、それともより重要なものに進むべきですか？
- あなたは私にYを提案しているので、その動作をキャッチしてテストできるように、少なくとも1つのテストケースを理解できますか？コードは呼び出されないと思います。
- 最初に、カバーされていないケースに対する安全なフォールバックを開発すべきではないでしょうか？したがって、それらを早期にキャッチして外出先で修正し、より重要なことに集中できるようにします。
- はい、私はYを実装していますが、そのためのテストケースを書いていただけますか一度だけ、そして全部？
- 私はXをするように要求されました、そして、他の優先順位がない限り私はYをすることができると思います。 次回は、私のコードにレビューコメントとして追加する代わりに、機能リクエストを提出してみませんか？少なくとも、その機能を実装する前に、他のチームメンバーからその機能についてさらに意見を聞くことができます（通常重要なものはすべて機能である必要があり、複数の人が処理する必要があります。通常はコードreviewはコードとソリューションのアプローチのレビューに関するものでなければなりません。残りはバグ修正と機能です）。
レビュアーの態度がプロジェクトに損害を与えていると真剣に考えていますかまたは彼はほとんど正しいと思いますか（たまに例外です）彼は評価で小さなエラーを作り、それを誇張しています）？
私にとっては、彼がコードレビューに属さないものを書いているように聞こえますが、それは誰もがものを追跡するのを難しくするので、悪い習慣です。しかし、私は彼が他にどんなコメントをしたかわからないので、他のケースについては何も言えません。
一般に、次の両方を回避するようにしてください。
- あなたは要求されたことをしていません
- レビュアーを馬鹿げた感じにする
彼があなたのコードを実際にレビューしているのは、経営者があなたよりも彼を信頼しているからです。