ありそうもないエッジケースに関するコードレビューの不一致をどのように処理しますか？

私はパスカバレッジチームのロボティクススタートアップで働いており、プルリクエストを送信した後、コードがレビューされます。

私のチームメイトは、チームに1年以上在籍しており、必要と思われるよりもはるかに多くの作業を行うことを示唆するコメントをコードに書きました。いいえ、私は怠け者の開発者ではありません。良いコメント、変数名、インデントを持ち、ケースを適切に処理するエレガントなコードが大好きです。しかし、彼は私が同意しない別のタイプの組織を念頭に置いています。

例を示します。

私は、自分が作成した遷移発見アルゴリズムの変更に関するテストケースを書くのに1日を費やしていました。彼は、私が発生する可能性が極めて低い不明瞭なケースを処理することを提案していました。実際、それが発生する可能性すらわからないのです。私が作成したコードは、元のテストケースのすべてと、私が見つけたいくつかの新しいテストケースで既に機能しています。私が作成したコードは、毎晩実行される300以上のシミュレーションに既に合格しています。ただし、このあいまいなケースを処理するには13時間かかり、ロボットのパフォーマンスを改善するために費やすことができます。明確にするために、これまで使用していた以前のアルゴリズムもこの不明瞭なケースを処理せず、生成された4万件のレポートでは一度も発生しませんでした。私たちは新興企業であり、製品を開発する必要があります。

私は以前にコードレビューをしたことがなく、私が議論しすぎているかどうかはわかりません。私はただ静かになって、彼が言うことをするべきですか？時間を有効に活用することに強く反対しているにもかかわらず、頭を下げて変更を加えることにしました。

私は同僚を尊敬し、彼が知的プログラマーであることを認めています。私はある点で彼に異議を唱えているだけで、コードレビューで不一致を処理する方法がわかりません。

私が選んだ答えは、ジュニア開発者がコードレビューで意見の相違をどのように処理できるかを説明するというこの基準を満たしていると感じています。

発生する可能性が極めて低い不明瞭なケース-実際、発生する可能性すらわからない

コードに未テストの動作がないことは非常に重要です。たとえば、1秒間に50回コードを実行すると、約5.5時間ごとに100万分の1の確率で発生します。（あなたの場合、確率は低いようです。）

優先順位については、マネージャー（またはあなたが働いているユニットのより上級の担当者）と話すことができます。たとえば、コードのパフォーマンスに取り組むか、コードが防弾であるかが最優先事項であるかどうか、そしてそのようなケースがどれほどありそうにないかをよりよく理解できます。また、レビュアーは優先順位について偏った考えを持っている場合があります。担当者と話をすると、レビュアーの提案に簡単に（反対に）同意できるようになり、参照することができます。

複数のレビュアーがいることは常に良い考えです。コードが1人の同僚によってのみレビューされる場合は、そのコードまたはコードベース全般を知っている他の人に調べてもらいます。セカンドオピニオンは、レビュアーの提案に簡単に（反対に）同意するのに役立ちます。

いくつかのコードレビュー中に何度もコメントが繰り返されることは、通常、明確に伝えられていないより大きなものを指し、同じ問題が繰り返し発生します。その大きなことを見つけて、レビュー担当者と直接話し合うようにしてください。質問する理由を十分に尋ねてください。コードレビューの練習を始めたとき、それはとても助けになりました。

災害の原因となることは決してあり得なかったコーナーケースの例を挙げることができます。

場合アリアン4は、横方向からの値を開発された加速度計に収まるようにスケーリングされた16ビット符号付き整数と加速度の最大可能出力は、スケーリングされた場合、可能性があるため、決して 32767を超える超えないと最小可能性が決して下回りません- 32768「範囲チェックのオーバーヘッドが不要」。一般に、すべての入力は変換前に範囲チェックされることになっていますが、この場合、不可能なコーナーケースをキャッチしようとしています。

数年後、Ariane 5が開発され、横方向の加速度計をスケーリングするためのコードは「実証済み」であるため、最小限のテストで再利用されました。残念ながら、より大きなロケットはより大きな横方向の加速度を期待できるため、加速度計がアップグレードされ、より大きな64ビットの浮動小数点値が生成される可能性がありました。

変換コードに「ラップ」これらの値が大きいほど、覚えていない何の範囲チェックを、そして1996年に最初の起動時に結果が良くありませんでした。会社に数百万の費用がかかり、プログラムに大きな中断が生じました。

私がしようとしている点は、決して発生しない、非常にありそうもないなどのテストケースを無視してはならないということです。彼らがコーディングしていた標準は、すべての外部入力値の範囲チェックを要求しました。それがテストされ処理されていれば、災害は回避された可能性があります。

Ariane 4では、これはバグではなかったことに注意してください（すべての可能な値に対してすべてがうまく機能したため）。これは標準に従わなかったためです。コードが別のシナリオで再利用された場合、致命的に失敗しましたが、値の範囲が切り取られていた場合は正常に失敗し、このためのテストケースの存在が値のレビューをトリガーした可能性があります。また、コード作成者とテスターが爆発後に調査員から批判を受けた一方で、経営陣、QA、およびリーダーシップが責任の大半を残したことも注目に値します。

明確化

すべてのソフトウェアが安全性を重視しているわけではなく、失敗したときでもそれほど壮観ではありませんが、私の意図は「不可能な」テストに価値があることを強調することでした。これは私が知っている最も劇的なケースですが、ロボット工学は悲惨な結果をもたらすこともあります。

個人的に、誰かがテストチームにコーナーケースを強調したら、それをチェックするためにテストを実施すべきだと思います。実装チームのリーダーまたはプロジェクトマネージャーは、見つかった障害に対処しないことを決定する場合がありますが、欠点が存在することに注意する必要があります。あるいは、テストが複雑すぎたり、実装するには費用がかかりすぎる場合、使用中のトラッカーやリスクレジスタで問題を提起して、これが未テストのケースであることを明確にすることができます。使用の変更前または不適切な使用の防止。

以前は処理されていなかったため、作業の範囲外です。あなたまたはあなたの同僚は、このケースをカバーするのに努力する価値があるかどうか、マネージャーに尋ねることができます。

複雑なアルゴリズムでは、現実の世界で発生するすべてのテストケースについて考えたことを証明するのは非常に困難です。テストケースが現実の世界で発生しないために意図的に壊れたままにしておくと、まだ考えていない他のテストケースが壊れたままになる可能性があります。

多くの場合に発生する他の効果は、追加のテストケースを処理すると、アルゴリズムが必然的により一般的になることです。そのため、すべてのテストケースでそれを簡素化し、より堅牢にする方法を見つけます。これにより、今後のメンテナンスとトラブルシューティングの時間を節約できます。

また、野生で発生する「これは絶対に起こらない」バグのケースは数多くあります。これは、アルゴリズムは変わらないかもしれませんが、この未処理のユースケースについて誰も覚えていないときに、その入力が今後何年も変わる可能性があるためです。そのため、経験豊富な開発者は、この種のことを思いついたときに処理します。そうしないと、後で噛みつきます。

これは技術的な質問ではなく、ビジネス戦略の決定です。提案された修正は、ほとんど発生しない非常にあいまいなケースに対するものです。ここでは、おもちゃをプログラミングしている場合、または医療機器や武装ドローンなどをプログラミングしている場合に大きな違いが生じます。まれな誤動作の結果は非常に異なります。

コードレビューを行う場合、まれなケースの処理に投資する金額を決定する際に、ビジネスの優先順位の基本的な理解を適用する必要があります。ビジネスの優先順位の解釈で同僚と意見が合わない場合は、ビジネスの面で誰かと話し合いたいと思うかもしれません。

コードレビューは、純粋にコードの正確性に関するものではありません。現実には、知識の共有と、チームスタイル/デザインコンセンサスの作成に向けたゆっくりではあるが安定したプロセスの背後にある、メリットのリストのかなり下にあります。

あなたが経験しているように、「正しい」とみなされるものはしばしば議論の余地があり、誰もがそれが何であるかについて独自の角度を持っています。私の経験では、限られた時間と注意もコードレビューを非常に不整合にする可能性があります。同じ開発者が、同じ開発者によって異なる時期に同じ問題が取り上げられるかどうかは異なります。「このコードを改善するものは何ですか？」という考え方のレビュアー 多くの場合、自然に自分の努力に追加しない変更を提案します。

経験豊富なコーダーとして（開発者として15年以上）、私よりも経験が浅いコーダーから頻繁にレビューを受けています。時々、彼らは私に軽度に同意しない、または重要でないと思う変更を求めます。しかし、私はまだそれらの変更を行います。最終結果が製品の脆弱性を引き起こし、時間コストが非常に高い場合、または「正しい」視点を客観的にすることができる場合にのみ、変更を巡って戦います。 t使用している言語で作業するか、ベンチマークでパフォーマンスの改善が主張されていることは示されていません）。

だから私はあなたの戦いを慎重に選ぶことを提案する あなたが必要ではないと思うテストケースをコーディングする2日間は、おそらく戦うための時間/努力の価値はありません。GitHubプルリクエストなどのレビューツールを使用している場合は、異議を指摘するためにあなたが知覚するコスト/ベネフィットについてコメントするかもしれませんが、それでも作業を行うことに同意します。これは穏やかなプッシュバックとしてカウントされるため、レビューアは境界に到達していることを認識し、さらに重要なことに、このようなケースがデッドロックに陥った場合にエスカレーションできるように、根拠を含めます。書面による意見の相違をエスカレートすることを避けたい-仕事の違いについてインターネットフォーラムスタイルの議論を持ちたくない-最初に問題を話し合い、議論の結果の公正な要約を記録しておくと役立つ場合があります。とにかく両方の友好的な議論があなたのために決定します）。

イベント後、これはスプリントレビューまたは開発チームの計画会議などに適したトピックです。たとえば、「コードレビューでは、開発者Aがこの追加のテストケースを特定しました。チームは、追加費用がこの費用で正当化されたと考えていますか？」-実際に作業を行うと、このアプローチははるかにうまく機能します。これは肯定的な見方であなたを示します。作業を完了し、リスク回避と機能開発についてチームにポーリングしたいだけです。

少なくともあいまいなケースに対して主張することをお勧めします。そうすれば、将来の開発者は、あなたが積極的にケースに反対することを決定するだけでなく、すでに適切な障害処理が行われているはずなので、これも驚くでしょう。

そして、その失敗をアサートするテストケースを作成します。これにより、動作がより適切に文書化され、単体テストで表示されます。

この答えは明らかに、「可能であっても極めて可能性が低い」というあなたの判断が正しいと仮定しており、私たちはそれを判断することはできません。しかし、そうであり、あなたの同僚が同意すれば、イベントに対する明示的な主張はあなたとあなたの両方にとって満足のいく解決策であるはずです。

そこに新しいように見えるので、できることは1つだけです。チームリーダー（またはプロジェクトリーダー）に確認してください。13時間はビジネス上の決定です。一部の企業/チームでは、多くの場合; いくつかのために、何も。まだあなたの決断ではありません。

リードが「そのケースをカバーしてください」と言ったら、問題ありません。彼が「いや、それをねじ込む」と言ったら、罰金-彼の決定、彼の責任。

一般的なコードレビューについては、リラックスしてください。タスクが1回または2回返されるのは完全に正常です。

@SteveBarnesの回答で少し取り上げられたものの、実際に対処されたことはないと思います。

失敗の影響は何ですか？

一部のフィールドでは、失敗はWebページのエラーです。PCのブルースクリーンが表示され、再起動します。

他の分野では、それは生か死です-自動運転車がロックします。医療ペースメーカーが機能しなくなります。またはスティーブの答え：ものが爆発し、数百万ドルの損失になります。

これらの極端には違いの世界があります。

「障害」をカバーするために13時間を費やすことが最終的に価値があるかどうかはあなた次第ではありません。管理者と所有者次第です。彼らは全体像を感じる必要があります。

何が価値があるのか​​をよく推測できるはずです。ロボットは単に減速または停止しますか？パフォーマンスの低下？または、ロボットの故障は金銭的損害を引き起こしますか？命の損失？

その質問に対する答えは、「会社の時間の13時間の価値がある」という答えにつながるはずです。通知：会社の時間を言った。彼らは法案を支払い、最終的にそれが価値があるものを決定します。経営陣はどちらの方法でも最終決定権を持つべきです。

たぶん、仕事の優先順位付けを担当する人に相談してください。スタートアップでは、CTOまたは製品所有者である可能性があります。彼は、この追加の作業が必要かどうか、そしてその理由を見つけるのを助けることができました。また、毎日のスタンドアップ中に心配を持って来ることができます（もしあれば）。

作業計画に明確な責任（製品所有者など）がない場合は、周囲の人と話してみてください。後になって、誰もが製品を反対方向に押し進めているという問題になる可能性があります。

意見の相違を処理する最良の方法は、あなたがジュニア開発者かシニア開発者か、CEOであるかに関係なく同じです。

Columboのように振る舞います。

コロンボを見たことがないなら、それはとても素晴らしいショーでした。コロンボはこの非常に控えめなキャラクターでした-ほとんどの人は彼が少し狂っていて心配する価値がないと思っていました。しかし、謙虚に見えて、人々に彼に彼を得ることができたと説明するように頼むことによって。

ソクラテスの方法にも関係していると思います。

一般的に、あなたはあなた自身や他の人に質問をして、あなたが正しい選択をしていることを確認したいと思うでしょう。「私は正しい、あなたは間違っている」という立場からではなく、正直な発見の立場から。または少なくとも可能な限り最高。

あなたの場合、ここには2つのアイデアがありますが、根本的に同じ目標があります。コードを改善することです。

あなたは、他の機能の開発を支持して、ありそうにない（不可能？）ケースのコードカバレッジをスキップすることが、それを行う最良の方法であるという印象を受けています。

あなたの同僚は、コーナーケースにもっと注意を払うことがより価値があるという印象を受けています。

彼らはあなたが見ないことを何を見ますか？見えないものは何ですか？ジュニア開発者として、あなたは自然に質問をしなければならないので、あなたは実際に素晴らしい地位にいます。別の回答では、誰かが驚くほどありそうなコーナーケースであると述べています。「X、Y、Zが欠けているという印象を受けていましたか？なぜウィジェットは荒れ果てますか？私はそれが混muとした状況では気が滅入るだろうという印象を受けていました。スウィズルスティックは実際にANZAブラシを強調しますか？」

仮定と結果に疑問を投げかけると、掘り下げ、バイアスを明らかにし、最終的に正しい行動方針を把握します。

チームの全員が完全に合理的であり、彼らがあなたと同じようにチームと製品の最大の利益を持っているという前提から始めます。彼らが意味をなさない何かをしているなら、あなたは彼らがすることを知らないこと、またはあなたが彼らがしないことを知っていることを理解する必要があります。

13時間はそれほど大したことではありません。あなたはそれに支払われていることを忘れないでください。それを「ジョブセキュリティ」と書くだけです。また、チーム間で良いカルマを保つことが最善です。1週間以上かかる場合は、上司を巻き込んで、それがあなたの時間の最適な使い方であるかどうか、特に同意しない場合は彼に尋ねることができます。

ただし、グループでレバレッジが必要なように聞こえます。レバレッジを得る方法は次のとおりです。許しを求めるのは許可を求めないでください。必要に応じてプログラムに項目を追加し（コースの範囲内、つまり上司が望んでいる問題を完全に解決するようにしてください）、事実をマネージャーまたは同僚に伝えてください。「機能Xを追加しても構いませんか」と尋ねないでください。むしろ、個人的にプログラムに必要な機能を追加するだけです。新しい機能に動揺したり同意しない場合は、削除しても問題ありません。彼らがそれを好めば、それを保ちなさい。

さらに、彼らがあなたに何かをするように頼むときはいつでも、「余分なマイル」に行き、彼らが言及するのを忘れたものまたは彼らが言ったよりもうまくいくものをたくさん追加します。しかし、彼らがそれ以上の距離を行くのが「大丈夫」かどうか彼らに尋ねないでください。それをして、それが終わった後、何気なく彼らにそれについて話してください。あなたがしているのはそれらを訓練することです。

何が起こるかは、あなたのマネージャーがあなたを「go-getter」としてペッグし、あなたに信頼を置き始め、あなたの同僚はあなたがプログラムを所有し始めている先駆者としてあなたを見るようになります。そして、あなたが言及したようなことが将来起こる場合、あなたは本質的にチームのスターであり、あなたが彼らに同意しない場合、チームメイトは後退するので、あなたはより多くのことを言うでしょう。

コードレビューにはいくつかの目的があります。明らかに気づいているのは、「このコードは目的に合っていますか？」です。つまり、機能的に正しいですか。適切にテストされていますか？非自明な部分は適切にコメントされていますか？プロジェクトの規約に準拠していますか？

コードレビューの別の部分は、システムに関する知識の共有です。作成者とレビューアの両方が、変更されたコードと、それがシステムの他の部分とどのように相互作用するかについて学ぶ機会です。

3番目の側面は、変更が行われる前に存在していた問題のレビューを提供できることです。かなり頻繁に、他の人の変更を確認するときに、以前の反復で見落としたものを見つけます（かなり頻繁に自分のものです）。「これは、これを以前よりも堅牢にする機会です」というような文言は批判ではなく、それを1つと見なさないでください。

私の現在のチームは、コードレビューを、コミットする前にコードを無傷で渡す必要があるゲートウェイまたはハードルとしてだけでなく、主に特定の機能領域についてある程度構造化された議論の機会と見なしています。情報共有のための最も生産的な機会の1つです。（そして、それは常に同じレビュアーではなく、チーム全体でレビューを共有する正当な理由です）。

コードレビューを対立的な活動とみなす場合、それは自己実現的な予言です。代わりに、それらをあなたの仕事の最も協力的な部分とみなすと、彼らはあなたの製品とあなたが一緒に働く方法の継続的な改善を刺激します。レビューが提案の相対的な優先順位について明確にできる場合に役立ちますx。たとえば、「ここに役立つコメントが欲しい」と「これがネガティブな場合、これは中断します」とは少し違いがあります。

上記の一般的な声明をたくさん作成しましたが、それはあなたの特定の状況にどのように当てはまりますか？私のアドバイスが、未解決の質問でレビューに応答し、どのアプローチが最も価値があるかを交渉することであることが今では明白であることを願っています。追加のテストが提案されている例の場合、「はい、それをテストできます。実装に<time>がかかると推定します。メリットは価値があると思いますか？テストが必要ないことを保証することができますか？」

あなたの質問を読んだときに私を驚かせる1つのこと：新しいテストケースを書くのに2日間の努力が必要な場合、新しいテストは既存のテストとは非常に異なるシナリオです（その場合、おそらく多くの値）またはテストスイートでコードの再利用を改善する必要性を特定しました。

最後に、コードレビューの価値に関する一般的なコメントとして（および上記で述べた内容の簡潔な要約として）、ダニエルヴェッターの「メンテナーズスケールしない」のこの声明が気に入っています。

少なくとも私にとって、レビューとは、優れたコード品質を確保することだけでなく、知識を広め、理解を向上させることでもあります。最初は、コードを理解している1人の人物、つまり作成者（そしてそれは与えられていません）が存在する可能性があります。十分に検討した後、コーナーケースを含め、少なくとも2人で完全に理解する必要があります。

コードは常に改善できます。

コードレビューを行っているときに、改善できる可能性のあるものやバグをキャッチする可能性のある単体テストが表示されない場合は、完璧なコードではなく、仕事をしていないレビュアーです。改善について言及することを選択したかどうかは個人的な選択です。しかし、ほとんどの場合、チームがコードレビューを行うときは、誰かが気づいた方が良いかもしれないし、誰もが時間を無駄にしているはずです。

つまり、コメントに基づいて行動するかどうかはチーム次第です。変更によって問題が修正されるか、チームが受け入れられるほどの価値を変更なしで追加したら、それらをマージしてコメントをバックログに記録し、誰かが後で対処できるようにします。チームがあなたの変更が価値よりもリスクまたは複雑さを追加すると判断した場合、それに応じて問題を解決する必要があります。

ちょうどことを覚えておいてください任意のコードをテストすることができ、少なくとも1以上のエッジケースを有し、少なくとも1つの以上リファクタリングを使用することができます。これが、コードレビューがグループとして最もよく行われ、全員が同時に同じコードを見ている理由です。最終的に、レビュー中のコードが（そのまま）受け入れられるかどうかについて全員が合意に達し、コミュニティベースにマージするのに十分な価値を追加するか、マージするのに十分な価値がある前に特定のことを行う必要がある場合。

この質問をしているので、実際に「コードレビュー」を行うのではなく、プルリクエストまたは他の送信メカニズムを作成して、他者が非決定的な方法でコメントするようにします。だから今、あなたは管理の問題と完了の定義になっています。あなたの経営陣は優柔不断で、コードレビューのプロセスと目的を実際に理解しておらず、おそらく「完了の定義」（DOD）を持っていないと思います。彼らがそうすれば、あなたのDODがこの質問に明示的に答えてくれるので、ここに来て尋ねる必要はないからです。

どのように修正しますか？さて、マネージャーにDODを提供して、常にすべてのコメントを実装する必要があるかどうかを尋ねてください。問題の人物があなたの上司である場合、答えは自明です。

この質問は、防御的なプログラミングの美徳、コーナーケースの危険性、または物理的な製品のバグの壊滅的なリスクに関するものではありません。実際、それはソフトウェアエンジニアリングに関するものではありません。

それは本当に後輩が同意または感謝できない場合に後輩開業医が上級開業医からの指示をどのように扱うかということです。

ジュニア開発者であることを評価する必要があることが2つあります。第一に、それはあなたが正しい状態にあり、彼が間違っている可能性がある一方で、それは-確率のバランスで-ありそうもないことを意味します。あなたの同僚があなたの価値を見ることができないという提案をしている場合、あなたはそれを理解するのに十分な経験がないという可能性を真剣に楽しまなければなりません。私はこの投稿からその意味を理解していません。

感謝すべき2番目のことは、あなたのシニアパートナーがより多くの責任を持っているため、いわゆるシニアパートナーであることです。後輩が何か重要なことを破ったとしても、指示に従えば問題になりません。ただし、シニアが、たとえばコードレビューで問題を提起しないことで、彼らがそれを破ることを許可した場合、彼らは非常に面倒なことになります。

最終的には、ビジネスを信頼する人々からの指示に従ってプロジェクトをリードすることが、あなたの仕事の暗黙の要件です。経験を評価する正当な理由がある場合、一般的に高齢者に先送りすることはできませんか？理解できない指示に従わないつもりですか？納得するまで世界は止まると思いますか？これらの値は、チームでの作業とは互換性がありません。

最後のポイント。6か月前に書いたプロジェクトを思い出してください。大学で書いたプロジェクトを考えてください。彼らが今どのように悪いかを見てください-すべてのバグと逆さまのデザイン、盲点と見当違いの抽象化？6か月後にあなたが今日している仕事とまったく同じ欠陥を数えると言ったらどうなるでしょうか？これは、現在のアプローチで死角がいくつあるかを示すのに役立ちますか？それは経験が生み出す違いだからです。

必要以上に多くの作業を行うことを示唆するコメントを常にコードに付けています。

推奨事項を提示できますが、最終的に必要なものを決定するのはあなたの役割ではありません。管理者（またはこの場合はレビュアー）が必要と判断したものを実装するのはあなたの仕事です。必要なものが多すぎたり強すぎたりすることに異議を唱えると、仕事から抜け出すことになります。その結果、これに妥協し、それと平和になることはあなたのプロフェッショナリズムの一部です。

彼は私が非常に起こりそうにないあいまいなケースを処理することを提案していました

どのようにしても非バグ（証明可能に失敗することはできませんすなわち。何かを示し、ここで他の偉大な答えがあり、これまで）まだ時々再加工する必要がありますが。（たとえば、製品の将来の安全性、標準に従うなどの場合）優れた開発者の役割の一部は、考えられるあらゆる状況でコードが常に堅牢であるという、可能な限り多くの自信を持つことです。 - ほとんどの場合、現在の条件下でテストされた状況で作業するだけでなく、校正済み

コードレビューのビジネス上の有用性を高めるためのコードレビュー担当者への提案（OPはそのような変更を提案する必要があります）：

• タイプごとにコメントを書き留めます。「クリティカル」/「必須」/「オプション」/「推奨される改善」/「持っていると良い」/「気分が悪い」。

  これがCDO / anal / complicatedのように思える場合、少なくとも2つのレベルを使用します：「レビューに合格し、変更をマージできるように修正する必要があります」/「その他すべて」。

作成することがそれほど重要ではないと思われるコードレビューの提案を処理するための提案：

• 選択したチケットシステムでオープンチケットを作成し（チームが使用することを希望しますか？）、提案を追跡します

• プロセスでFisheyeや電子メールレビューのようなコメントへの応答が許可されている場合、コードレビューアイテムへの応答コメントとしてチケット＃を入れます。

• レビューアに連絡して、そのアイテムが「修正する必要があるか、マージ/リリースされない」タイプかどうかを明示的に尋ねます。

  • 答えが「はい」であるが、同意しない場合は、プロジェクト管理の責任者（PM、マネージャーなど）に意思決定を任せてください-不一致を完全かつ正直に提示してください。これは、あなたのどちらが「正しい」かではなく、プロジェクトにとって何が良いかということなので、PM /マネージャーの仕事です。

次に、そのチケットを他の開発リクエストとして扱います。

1. エスカレーション後に緊急であると判断された場合は、緊急の開発リクエストとして扱います。他の作業の優先順位を下げ、これに取り組みます。

2. それ以外の場合は、割り当てられた優先度とそのROI（他の回答で説明されているように、ビジネスラインに基づいて異なる場合があります）に従って作業します。

これを経営陣にエスカレートしないでください。

ほとんどの企業では、管理者は常に余分なテストを記述せず、コード品質をわずかに改善する時間を費やさず、リファクタリングに時間を費やさないことを選択します。

多くの場合、コードの品質は開発チームの未記述のルールとプログラマーの追加の努力に依存します。

あなたはジュニア開発者であり、これがあなたの最初のコードレビューです。あなたはアドバイスを受け入れ、仕事をしなければなりません。チーム内のワークフローとルールを改善することができるのは、最初にそれらをしばらく知って尊重し、その理由を理解できるようにする場合のみです。そうでなければ、あなたはルールを尊重せず、チームの孤独なオオカミになる新しい男になります。

あなたはチームに慣れていないので、しばらく得たアドバイスに従ってください。彼らがそこにいる理由を見つけてください。スクラムミーティングで最初に問題になったアドバイスを持ってこないでください。しばらく経つと、実際のビジネス上の優先事項は尋ねることなく明白になります（そして、経営者があなたに向かい合って言うことではないかもしれません）。

リード/管理の要求を満たすコードを作成することは非常に重要です。その他の詳細は、「持っておくといい」だけです。あなたがあなたの分野の専門家である場合（「あなたがジュニア開発者でない場合」を読んでください）、あなたはリーダーに毎回相談することなく、途中で見つけた軽微な問題に対処することができます。

何かがおかしいと思っていて、自分の分野の専門家であれば、その可能性は高いでしょう。

役に立つと思われるステートメントを次に示します。

• Xを行うように要求されましたが、コードレビューアーはYを行うことも提案しています。
• あなたは私にYを提案しているので、その動作をキャッチしてテストできるように少なくとも1つのテストケースを見つけることができますか？コードは呼び出されないと思います。
• 最初に、発見された事例の安全なフォールバックを開発すべきではないでしょうか？そのため、より重要なものに集中できるように、それらを早期にキャッチして外出先で修正します。
• OK、私はYを実装していながら、あなたはそれのためにいくつかのテストケースを書くことがとても親切にすることができ、私たちはそのことを成し遂げる一度、すべての？
• Xを実行するように要求されましたが、他に優先順位がなければYを実行できると思います。次回は、コードのレビューコメントとしてではなく、機能リクエストを提出してみませんか？少なくとも、実装する前に、その機能について他のチームメンバーからさらに意見を聞くことができます（一般に、重要なものは機能であり、複数の人が処理する必要があります。通常、コードレビューは、コードとソリューションのアプローチのレビューに関するものである必要があり、残りはバグ修正と機能です）。

あなたは真剣にあなたのレビューアの態度がいると思いますプロジェクトにダメージを与えるか、あなたは彼だと思います右のほとんどの時間（多分、時には彼はちょうど評価に軽微なエラーを行い、ことを誇張除きますか）？

私には、彼がコードレビューに属さないものを書いているように思えます。しかし、私は彼が他にどのようなレビューコメントをしたのかわからないので、他のケースについては何も言えません。

一般的に、次の両方を避けるようにしてください。

• あなたは要求されたことをしていない
• あなたはレビュアーに愚かさを感じさせます

彼が実際にあなたのコードをレビューしているのは、管理者があなたよりも彼を信頼しているからです。

コードレビュー中にスコープについて意見の相違がある場合：

1. 実際にコードでカバーされる範囲を文書化します。誰も厄介な驚きを好きではありません。
2. その範囲がビジネス上の決定であることを認識してください。機能の作業を開始するまでにスコープはすでにわかっているはずですが、そうでない場合は、後でいつでも説明を求めることができます。

コードレビュー担当者がビジネス上の意思決定を行う場合、コードレビュー中であってもいつでもスコープを変更できますが、コードレビュー担当者としての役割ではそうしていません。

エッジケースが不可能であることを証明できない場合は、可能だと想定する必要があります。可能であれば、それが最終的に発生することは避けられません。テストでエッジケースが発生していない場合は、テストカバレッジが不完全である可能性があります。

1. フィードバックを受け入れます。
2. コードに変更を加える前に、エッジケースのテストを作成し、テストの失敗（問題の存在の証明）を取得できるかどうかを確認してください。そのようなテストケースを作成してテストの失敗を取得することが不可能な場合、エッジケースは実際には不可能であると結論付けることができます（そのような結論を出すのをためらいますが）。
3. テストに失敗した場合は、適切なコード変更を適用してテストに合格してください。

製品の利益のために、おそらく修正を適用し、潜在的な問題が回避されたことを確信できるように、エッジケースを生成して障害を誘発できるようにする必要があります。

コードレビューの目的は、コードにさらに目を向けることです。私たちは誰も間違いや見落としから免れません。コードの一部を何度も見て、明らかなエラーに気付かないことはあまりにも一般的です。そこでは、新しい目ですぐにそれを見つけることができます。

あなたが言ったように、新しいアルゴリズムを実装しました。新しいアルゴリズムの動作またはその前身に関する観察に基づいて、新しいアルゴリズムの動作について結論を出すのは賢明ではありません。

自分が何をしているのかを知っているコードレビューアがいて、何かを変更する必要があると言ったら、それを変更する必要があり、テストする必要があると言ったら、テストする必要があります。

他の人のために役に立たない作品を作成することによって自分の存在を正当化する必要があるコードレビューアがいます。

どちらを決めるかはあなた次第です。そして、2番目の種類をどのように扱うかは、workplace.stackexchangeにとってはもっと問題です。

スクラムを使用する場合、問題は作業が本来行うべきことを実行するか（明らかに実行するか）です。また、非常にまれであり、おそらく不可能なケースをバックログで処理することができます。スプリントに入ると、レビュアーが気軽に拾い上げて13時間の作業を行うことができます。ジョブXを実行し、ジョブXを実行するため、ジョブYも実行する必要があることに気付いた場合、ジョブYはジョブXの一部にはならず、それ自体が独立したジョブになります。