コードレビューでは、レビュー担当者は常に問題の解決策を提示する必要がありますか？[閉まっている]

コードをレビューするとき、私は通常、問題を解決する方法について特定の推奨事項を作成しようとします。しかし、レビューに費やすことができる時間が限られているため、これは必ずしもうまく機能するとは限りません。これらの場合、開発者が自分で解決策を考え出した方が効率的です。

今日、私はいくつかのコードをレビューし、クラスが明らかにうまく設計されていないことを発見しました。特定のオブジェクトにのみ割り当てられ、他のオブジェクトには空白のままになっているオプションの属性がいくつかありました。これを解決する標準的な方法は、クラスを分割して継承を使用することです。しかし、この特定のケースでは、このソリューションは物事を過度に複雑にしているように見えました。私は自分でこのソフトウェアの開発に関わっていなかったため、すべてのモジュールに精通していません。したがって、特定の決定を下すのに十分な知識があるとは感じませんでした。

私が何度も経験した別の典型的なケースは、明らかに意味のない、または誤解を招くような関数、クラス、または変数名を見つけたが、自分で良い名前を思い付くことができないことです。

それで、一般的に、レビュアーとして、「このコードには欠陥があるので...違う方法でやる」と言ってもいいですか、それとも特定の解決策を考え出す必要がありますか？

レビューアとしてのあなたの仕事は、コード（またはドキュメント）がレビュー前に合意された特定の目的を満たしているかどうかをチェックすることです。

これらの目標の一部には、通常、目標が達成されたかどうかの判断が含まれます。たとえば、コードが保守可能でなければならないという目的には、通常、判断が必要です。

レビューアとして、目的が達成されていない場所を指摘するのはあなたの仕事であり、彼の仕事が実際に目的を満たしていることを確認するのは著者の仕事です。このように、修正の方法を伝えるのはあなたの仕事ではありません。

一方、「これは欠陥です。修正してください」と著者に伝えるだけでは、通常、チーム内の雰囲気が良くなりません。ポジティブな雰囲気のために、少なくともあなたの目に欠陥がある理由を示し、もしあればより良い代替手段を提供することは良いことです。
それに加えて、「間違っている」ように見えるものをレビューしているが、より良い代替手段がない場合は、「このコード/デザインは私と相性が悪いが、私は明確な代替案はありません。これについて議論できますか？」そして、何かを一緒に改善しようとします。

ここでいくつかの良い答えがありますが、重要な点が一つ欠けていると思います。あなたがレビューしているコード、その人の経験、そのような提案の処理方法に大きな違いがあります。チームメイトをよく知っていて、「このコードには欠陥があるので、違うやり方でやってください」などのメモが彼または彼女がより良い解決策を考え出すのに十分であると期待する なら、そのようなコメントは大丈夫です。しかし、このようなコメントでは不十分であり、コードを改善する方法を正確に伝える必要がある人は間違いなくいます。だから私見これはあなたが個々のケースについてのみ行うことができる判断の呼び出しです。

それで、一般に、レビュアーとして、「このコードには欠陥がある、違うやり方で行う」と言ってもいいですか、それとも特定の解決策を考え出す必要がありますか？

どちらも理想的なIMOではありません。最善の方法は、著者と話し合い、問題を共同で修正することです。

コードレビューは非同期である必要はありません。官僚的なプロセスと見なすのをやめ、ライブコミュニケーションに少し時間をかけると、多くの問題が解き放たれます。

コードレビューでは、レビュー担当者は常に問題の解決策を提示する必要がありますか？

いいえ。レビュアーではないことをやっているなら、あなたは次のコーダーです。

コードレビューでは、レビュー担当者が問題の解決策を提示してはいけませんか？

いいえ。あなたの仕事は、当面の問題を伝えることです。解決策を提示することで問題が明確になる場合は、それを実行してください。私があなたのソリューションに従うことを期待しないでください。ここでできることは、ポイントだけです。実装を指示することはできません。

レビュー担当者が問題の解決策を提示する必要があるのはいつですか？

それが最も効果的なコミュニケーション方法であるとき。私たちは英語専攻ではなくコードサルです。時々、コードが悪いことを示す最良の方法は、最適ではありません...少ないコードを示すことです...より良い方法です...ああ、どういう意味かわかります。

主な問題は、人々がより良いコードの書き方を知っていれば、通常はそもそもそうするだろうということです。批判が十分具体的かどうかは、著者の経験に大きく依存します。非常に経験豊富なプログラマーは、「このクラスは複雑すぎる」などの批判を受けて、図面に戻って何か良いものを思い付くことができるかもしれません。なぜなら、彼らは頭痛のために休みをとったり、大急ぎで。

ただし、通常は、少なくとも合併症の原因を特定する必要があります。「このクラスは、至る所でデメテルの法則を破っているので複雑すぎます。」「このクラスは、プレゼンテーション層と持続層の責任を混同します。」それらの理由を特定して簡潔に説明することを学ぶことは、より良いレビュアーになるための一部です。ソリューションについて詳細に説明する必要はほとんどありません。

悪いプログラマーには2つのタイプがあります。標準的な慣行に従わないプログラマーと、標準的な慣行に「のみ」従うプログラマーです。

連絡先を限定したり、誰かにフィードバックを提供したりしても、「これは悪いデザインです」とは言いません。しかし、「このクラスを私に説明してもらえますか？」あなたはそれが良い解決策であることを発見するかもしれません。開発者は彼ができる限り最善を尽くしました。

応答に応じて、各状況と人にどのようにアプローチするかについて、より良いアイデアが得られます。彼らはすぐに問題を認識し、自分で修正を発見するかもしれません。彼らは助けを求めたり、自分で解決しようとするかもしれません。

私たちのビジネスには推奨プラクティスがありますが、ほとんどすべてに例外があります。プロジェクトとプロジェクトのアプローチ方法を理解している場合、それがコードレビューの目的と懸念への対処方法を決定するためのコンテキストになります。

これは、明示的な解決策というよりも、問題に対するアプローチの方が多いと思います。すべての状況をカバーするには、あまりにも多くの変動があるでしょう。

コードを確認するとき、私が特定した問題の解決策を提供するのは、ほとんど労力をかけずにできる場合だけです。私は問題があると思うものについて具体的にしようとしていますが、可能な場合は既存のドキュメントを参照します。レビュアーが特定されたすべての問題の解決策を提供することを期待することは、逆のインセンティブを生み出します-レビュアーが問題を指摘することを思いとどまらせます。

私の意見は、多くの場合、多くの場合にコードを提供しない方向に向かっています。

• 説明だけでは不十分な場合、彼らはいつでもあなたが考えていることのサンプルを求めることができます。
• 長い間触れなかったコードに少し慣れるだけで時間を無駄にすることはありませんが、他の誰かがそれを行うために時間を費やしているだけです。
• 彼らがすでにコードに精通していて、あなたがそうでないなら、フィードバックだけを与えると、あなたが書くよりも良いコードになるかもしれません。誰かに準備の整ったソリューションを提供すると、多くの場合、それをさらに改善することを考慮せずに、ただ使用するだけになります。
• 常にソリューションを提供することは、見下すことに境界を接しています。あなたは誰かと仕事をしているのですが、うまくいけば彼らは雇われるのに十分だったからです。何かが悪い考えである理由をなんとか理解できたなら、なぜ彼らはフィードバックを聞いてそれを自分でやることによってそれを学ばないのでしょうか？
• 常にソリューションを提供するのは奇妙です。あなたが彼らの机でペアプログラミングをしていると想像してください：彼らはあなたが素晴らしいとは思わない数行を終えたところです。見つけたものとその理由を伝えるだけですか、それともキーボードをつかんですぐにバージョンを表示しますか？これは、ソリューションを常に提供することが他の人に感じられることです。
• 実際に書く時間を費やすことなく、代わりに何をするかをいつでも言うことができます。あなたは質問の最初の問題を説明するときにそれをしました。
• 食べ物を渡さないで、釣り方を教えてください;）

確かに、いくつかの特定の代替案を考えている場合があり、それを添付する価値があります。しかし、それは私の経験では本当にまれです。（多くのレビュー、大きなプロジェクト）原作者は、必要な場合はいつでもサンプルを求めることができます。

それでも、3番目の理由により、サンプルを提供するときx.foo()は、完全な解決策ではなく、たとえば「使用するとこれがより簡単になる」と言う価値があります。これにより、時間も節約できます。

コードレビューの鍵は、レビューの前にルールに同意することだと思います。

明確なルールセットがある場合、ソリューションを提供する必要はありません。ルールが守られていることを確認しているだけです。

代替の質問が出てくるのは、元の開発者がルールに合った機能を実装する方法を考えられない場合だけです。パフォーマンス要件がありますが、最適化を何度か試みた後、この機能はしきい値より長くかかります。

しかしながら！ルールが主観的である場合「名前は私によって承認されなければなりません！」それから、はい、あなたは自分でチーフのネーマーを任命したので、受け入れ可能な名前のリストのリクエストを期待するべきです。

長いメソッドと「多すぎる」関数パラメーターを禁止するコードレビュールールを見たことがあるので、継承（オプションのパラメーター）の例の方がおそらく良いでしょう。しかし、通常、これらは分割することで簡単に解決できます。「このソリューションは物事を過度に複雑にしているように見える」部分であり、あなたの客観性が侵入し、おそらく正当化または代替ソリューションが必要です。

解決策の候補をすばやく簡単に入力できる場合は、ピアレビューのコメントに含めるようにします。そうでない場合、私は少なくとも自分の懸念とその特定のアイテムに問題があると思う理由をリストします。あなたがより良いものを考えることができない変数/関数名の場合、私は通常、私はより良いアイデアを持っていないことを認め、誰かができるように、自由回答形式の質問の形でコメントを終了します。そうすれば、誰もより良いオプションを思い付かない場合、レビューは実際には保留されていません。

質の悪い設計のクラスで、あなたが質問で与えた例について。やりすぎのように思えるかもしれませんが、コードが解決しようとしている問題に対処するには、おそらく継承が最善の方法であるというコメントを残します。私は、それがショーストッパーではなく、修正するかどうかは開発者の裁量に任されていることを示す方法で表現しようとします。また、コードのその部分に特に精通していないことを認めて開き、知識のある開発者やレビュアーに、その方法で行われた理由があるかどうかを明確にしてもらいます。

コードをレビューしている人と話をしてください。わかりづらいことをわかりやすく伝え、それをどうすればより明確にすることができるかを話し合います。

書面によるコミュニケーションは、膨大な時間の浪費に加え、resみや誤解を招きます。

向かい合って、帯域幅ははるかに高く、敵意を防ぐ感情的なサイドチャネルがあります。

実際にその人と話をすると、はるかに速くなり、新しい友達を作ることができ、両方の仕事をもっと楽しむことができます。