不要だと思われるコードレビューを拒否する方法

私は、自分が存在するとは思わない問題を修正するコードをレビューするように頼まれた立場にいます。

私よりも上級のフィクサーは、彼の修正が必要であると主張しますが、それは私にとってはC ++のso弁にすぎないようです。展開プロセスの一部はコードレビューであり、小規模企業で2番目に高いエンジニアとして、変更をレビューすることが期待されています。

レビュー担当者は元のコーダーと同じようにコードの変更に責任があると思いますが、この変更の責任を受け入れるつもりはありません。このレビューを拒否するにはどうしますか？

変更で成功する変更なしで失敗するテストケースを要求します。

彼が作成できない場合、それを正当化として使用します。

彼がそれを作成できる場合、テストが無効である理由を説明する必要があります。

レビューアは客観的でなければなりません。

検討する前に問題のコードについて意見を述べたことは明らかであり、あなたとフィクサーがポジションを賭けたようです。そうだとすれば、客観的に見える困難な時間を持ち、客観的になるのはさらに難しい時間になるでしょう。それはいずれもプロセスに役立ちません。そして、あなたができる最善の、最も客観的なことは、あなたが問題に近すぎるという理由に屈することかもしれません。

チームアプローチを検討してください。

自分自身を削除できない場合は、他の複数のエンジニアにコードを同時にレビューしてもらうことができます。コードが拒否されるべきであるかそうでないかについて彼らはあなたに同意するでしょう。彼らがあなたに同意すれば、それはもはやあなたとフィクサーだけではなく、チームが修正を客観的に見て、それを受け入れることに決めたというより強力なケースを作ることができます。一方、彼らが修正を受け入れることに決めた場合、それもチームの決定になります。できる限り心を開いて参加するべきであり、合理的な議論以外で他のチームメンバーの意見に影響を与えようとしてはならないことは言うまでもありません。重要：後で悪い結果が出た場合、「まあ私は」と言ってバスの下にチームを投げない 常にそれは悪いコードだと言っていましたが、私は他のチームメンバーに負けていました。」

拒否は、コードレビュープロセスの自然な部分です。

コードレビュープロセスは、より多くの高齢者からのゴム印の修正にはありません。コードの品質を保護および改善するためにあります。適切な理由、つまり修正によってコードが改善されないという理由で修正を拒否しても、問題はありません。ひたむきなコードのレビューを行った後でも、修正によって実証可能な問題のリスクや重大性が軽減されないと感じた場合は、拒否する必要があります。それは個人的なものではなく、あなたの正直な意見です。フィクサーが同意しない場合でも、それは問題ありません。その時点で、経営者が把握することが問題になります。正直で、オープンで、プロフェッショナルであることを忘れないでください。

責任は両方の方法を削減します。

問題があるとは思わないので、この変更に責任を持ちたくないと言いました。ただし、あなたが間違っていて問題がある場合は、問題を回避するコードを拒否する責任を負うことに気付く必要があります。

メモする。

レビュープロセスのログを書き留めておくことで、事実を正確に保つことができます。申し立てられた問題や修正などを測定するために実行する可能性のあるテストのレビュー、説明、結果中に考えや懸念を書き留めてください。問題がエスカレートした場合は、サポートのために行ったことを記録しますポジション。将来問題が再び発生する場合（おそらく、フィクサーが彼自身のビューにアタッチされている場合）、あなたはあなたの記憶を揺さぶるものがあります。

反論の可能性が高い場合の拒絶理由と抗弁理由を書き留めてください。その後、フィクサーと合理的に話し合い、必要に応じて経営陣にエスカレーションします。

十分なドキュメント（コードリスト、テスト結果、客観的な引数を含む）があれば、十分にカバーされます。

あなたはフィクサーに何らかの悪意を引き起こしますので、問題にそれだけの価値があることを確認してください（つまり、非修正が害を及ぼすのでしょうか？）

また、定着液が所有者に何らかの形で関連している場合は、この回答を忘れてください。

最近LinkedInのニュースで、workplace慢に見えるのではなく、職場での紛争解決と謙虚さについての記事がありました。残念ながら、今はリンクを見つけることができませんが、一般的な要点は、対立しない方法で質問を作成しようとすることでした。あなたが慢であると私が暗示しているので、これを受け取らないでください。それは記事が書かれた方法です。

とにかく、上級プログラマーに彼の仮定が間違っていると伝えることは、彼が防御的なアプローチを取り、彼の応答であなたを攻撃することにつながります。しかし、あなたが理解の欠如の観点から、問題が存在すると彼が信じる理由の質問を提起する場合、彼/彼女は問題を議論するためによりオープンになりそうです。

したがって、「問題は存在しないので、これを確認する必要はありません」と言うのではなく、「これを適切に確認するには、問題を理解する必要があります。あなたから説明してください。視点？"

一例として、この記事では、大人が直面しているものを除くすべてが単色の立方体を大人が持ち上げた子供に与えられたテストについて説明しました。大人が見ている色を子供たちに尋ねると、5歳未満の人は見ることができる色をほとんど常に言うでしょう。大人は自分とは異なる見方をすることができるとは理解できませんでした。

C / C ++は未定義の動作でいっぱいになる可能性があります。一方の手は、予期しない動作につながる可能性があるため、悪いです。一方、積極的な最適化が可能になり、通常、C / C ++を使用している場合は速度に関心があります。

壊れるテストケースを書くのは難しいかもしれません-それはもはや存在しない奇妙なアーキテクチャやコンパイラを伴うかもしれません。また、賢明なアーキテクチャでは「問題を引き起こすことはないはず」と思われるかもしれません。

ただし、ある時点でプラットフォームを変更します（たとえば、モバイルに移行してARMに移植するか、速度を上げてGPUを使用する）。この時点で状況が崩れ始める可能性があり、デバッグする必要があります。コンパイラを新しいバージョンに更新するのと同じくらい簡単な場合があります（必要な場合もあります）。

問題のあるコードは次のとおりです。

int d[16];

int SATD (void)
{
   int satd = 0, dd, k;
   for (dd=d[k=0]; k<16; dd=d[++k]) {
     satd += (dd < 0 ? -dd : dd);
   }
   return satd;
 }

最後の反復中にd[++k] => d[++15] => d[16]アクセスされます。通常、次の要素は（Cメモリモデルではなくページングに関して）正当なメモリであるため、些細なコンパイラでさえ、奇妙な動作をする実行可能ファイルを生成しませんでした。テストケースを記述する唯一の方法は、C（おそらくVM）とまったく同じメモリモデルを持つプラットフォームを見つけることでした。

しかしd[++k]、すべてのループで実行されるgcc 4.8 prerelaseが見られます。そうでk < 16なければ、アクセスは違法であり、コンパイラに供給されるプログラムの合法性は契約の一部です。したがって、仮定が与えられた場合、ループ条件は常に真であるため、無限ループになります。これは奇妙に聞こえるかもしれませんが、完全に合法的な最適化でした-放出system("dd if=/dev/zero of=/dev/sda"); system("format c:")はループの正しい置き換えにもなります。動作を表示するために選択できる微妙な方法があります。たとえば、トランザクショナルメモリに関する講義中に、2つのスレッドが同じ値をインクリメントしたときに、プレゼンターが間違った値を取得しようとしたことが何度かあったことを覚えています。

ただし、一部の言語とは反対に、C / C ++は標準化されているため、このような論争は客観的なソースを参照して行うことができます。

• これが問題ではないと思う場合は、 C / C ++標準を使用してそれを証明してみてください（つまり、定義された値と動作につながる）
• これが問題だと思う場合は、 C / C ++標準を使用してそれを証明するように依頼してください（つまり、未定義の値または動作につながる）

一般的に、チームがC / C ++で記述している場合、標準を手元に置いておくと便利です。チームの専門家でさえ、時々奇妙な何かを見つけることができます。

これは、この特定のレビューよりも、チームポリシーの問題のようです。私が9人のチームで大規模なソフトウェアショップで働いていたとき、校閲者はコードに対して拒否権を持っていました。これは私たち全員が尊敬する標準でした。私たちは十分に才能があり、十分な知識を持っていました-つまり。「成熟」しているが、「調味料入り」ではなく「幼稚ではない」という意味-チームリーダーは、慎重な時期に議論に巻き込まれることなく常に合意に達することができると合理的に期待できる。

単にあなたの投稿の言語に基づいて、私はあなたがこの状況に近づこうとしているように聞こえるかもしれないと警告するかもしれません。おそらくそれは「知的自慰」ですが、おそらく彼または彼女がそれをした理由があり、あなたの負担はその問題を解決するためのより簡単な方法を考え出すことです-そしてそのような方法が存在しない場合は、コメントで文書化してください実際、自慰行為のコードが必要でした。

提出者に、自分のコードが問題を解決したという証拠を見せてください。彼がテストし、あなたに証拠を示すことができれば、あなたは間違っている人であり、あなたの不平をやめて対処するべきです。問題があるという主張を裏付ける証拠を提示できず、パッチが問題を修正したという証拠を提示できない場合は、ドローリングボードに送り返します。

もちろん、これについては敏感な内部政治性があるかもしれません。しかし、これは私が行く方法です（嬉しいことに）。