コードレビューでは、レビュー担当者は常に問題の解決策を提示する必要がありますか？
コードをレビューするとき、私は通常、問題を解決する方法について特定の推奨事項を作成しようとします。しかし、レビューに費やすことができる時間が限られているため、これは常にうまくいくとは限りません。このような場合、開発者が自分で解決策を考え出す方が効率的です。
今日、私はいくつかのコードをレビューしましたが、クラスが明らかにうまく設計されていないことがわかりました。これには、特定のオブジェクトにのみ割り当てられ、他のオブジェクトには空白のままになっている多数のオプション属性がありました。これを解決する標準的な方法は、クラスを分割して継承を使用することです。ただし、この特定のケースでは、このソリューションは複雑すぎます。私は自分でこのソフトウェアの開発に関与したことはなく、すべてのモジュールに精通していません。したがって、私は特定の決定を下すのに十分な知識を持っているとは感じませんでした。
私が何度も経験したもう1つの典型的なケースは、明らかに無意味な、または誤解を招くような関数、クラス、または変数の名前を見つけたが、自分で適切な名前を付けられない場合です。
一般に、レビュー担当者として、「このコードには欠陥があるため、...違った方法で行う」と言ってもいいですか、それとも特定のソリューションを考え出す必要がありますか？
レビュー担当者の仕事は、コード（またはドキュメント）がレビュー前に合意された特定の目的を満たしているかどうかを確認することです。
これらの目的のいくつかは、通常、目的が達成されたかどうかの判断を求められます。たとえば、コードが保守可能でなければならないという目的には、通常、判断の呼びかけが必要です。
レビュー担当者として、目的が達成されていない場所を指摘するのはあなたの仕事であり、著者の仕事が実際に目的を達成していることを確認するのは著者の仕事です。このように、どのように修正を行う必要があるかを伝えるのはあなたの仕事ではありません。
一方、作者に「これは欠陥があります。修正してください」と伝えるだけでは、通常、チームの雰囲気は良くなりません。ポジティブな雰囲気の場合、少なくとも何かがあなたの目に欠陥がある理由を示し、もしあれば、より良い代替案を提供することは良いことです。
それ以外に、「間違っている」と思われるものをレビューしているが、本当により良い代替案がない場合は、「このコード/デザインはうまくいかない」という行に沿ってコメントを残すこともできます。私と一緒ですが、明確な代替案はありません。これについて話し合うことはできますか？」一緒にもっと良いものを作ってみてください。
ここで良い答えがいくつかありますが、重要な点が1つ欠けていると思います。それはあなたがレビューしているコード、その人がどれほど経験豊富であるか、そして彼または彼女がそのような提案をどのように処理するかという大きな違いを生みます。あなたのチームメイトをよく知っていて、"このコードには欠陥があるため、別の方法で実行してください。"コメントで結構です。しかし、そのようなコメントでは不十分で、コードを改善する方法を正確に説明する必要がある人は確かにいます。だから私見これはあなたが個々のケースに対してのみ行うことができる判断の呼び出しです。
一般的に、レビュー担当者として、「このコードには欠陥があるので、別の方法で行う」と言ってもいいですか、それとも特定のソリューションを考え出す必要がありますか？
どちらも理想的なIMOではありません。最善の方法は、作者に相談して、共同で問題を修正することです。
コードレビューは非同期である必要はありません。官僚的なプロセスと見なすのをやめて、ライブコミュニケーションに少し時間をかけると、多くの問題が解決されます。
コードレビューでは、レビュアーalwaysが問題の解決策を提示する必要がありますか？
いいえ。あなたがレビュアーでないことをしているのなら、あなたは次のコーダーです。
コードレビューでは、レビュアーneverが問題の解決策を提示する必要がありますか？
いいえ。あなたの仕事は目の前の問題を伝えることです。解決策を提示することで問題が明確になれば、それを実行してください。私があなたの解決策に従うことを期待しないでください。ここであなたがすることはポイントを作ることだけです。実装を指示することはできません。
レビュー担当者はいつ問題の解決策を提示する必要がありますか？
それが最も効果的なコミュニケーション方法である場合。私たちは英語の専攻ではなく、コードモンキーです。時々、コードが吸うことを示すための最良の方法は...最適ではない...吸うことが少ないコードを表示すること...はより最適です...ああ、地獄、私が何を意味するか知っています。
主な問題は、人々がコードをよりよく書く方法を知っていれば、通常、そもそもそうであったでしょう。批評が十分具体的であるかどうかは、作者の経験に大きく依存します。非常に経験豊富なプログラマーは、「このクラスは複雑すぎる」などの批判を受け入れ、設計図に戻って何か良いものを考え出すことができるかもしれません。大急ぎで。
ただし、通常は、少なくとも合併症の原因を特定する必要があります。 「このクラスは、あらゆる場所でデメテルの法則を破るので複雑すぎます。」 「このクラスは、プレゼンテーション層と永続層の責任を混同しています。」それらの理由を特定し、それらを簡潔に説明することを学ぶことは、より良いレビュアーになるための一部です。ソリューションについて詳しく説明する必要はほとんどありません。
悪いプログラマーには2つのタイプがあります。標準的なプラクティスに従っていないプログラマーと、標準的なプラクティスに従っているだけのプログラマーです。
連絡先が限られているか、誰かにフィードバックを提供しているときは、「これは悪いデザインです」とは言えません。 「このクラスについて説明してくれませんか？」あなたはそれが良い解決策であることを発見するかもしれません、開発者は彼ができる限り最善を尽くしたか、それが悪い解決策であるという認識さえもしましたが、それは十分に良いです。
応答に応じて、それぞれの状況と人にどのようにアプローチするかについて、より良いアイデアが得られます。彼らはすぐに問題を認識し、自分で修正を発見するかもしれません。彼らは助けを求めるかもしれませんし、自分で解決しようとするかもしれません。
私たちのビジネスには推奨されるプラクティスがありますが、それらにはほとんど例外があります。プロジェクトと、チームがプロジェクトにどのように取り組んでいるかを理解していれば、それがコードレビューの目的と問題への対処方法を決定するためのコンテキストになり得ます。
これは、明示的な解決策というより、問題へのアプローチのほうが多いことに気づきました。すべての状況をカバーするには、ばらつきが多すぎます。
コードをレビューするとき、私が特定できる問題の解決策を提供するのは、少しの努力でそれができるかどうかだけです。私は問題が何であると私が思うかについて具体的にすることを試みます、可能な場合は既存のドキュメントを参照してください。確認されたすべての問題の解決策を提供することをレビュアーに期待することは、ひどいインセンティブを生み出します-それはレビュアーが問題を指摘することを思いとどまらせるでしょう。
私の意見は、多くの場合にコードを提供しないことに向かって強くなっています。それには、いくつかの理由があります。
- それだけでは十分ではない場合、彼らはいつでもあなたが考えていることのサンプルを求めることができます。
- 他の誰かがそのために時間を費やしている間、少しだけ変更するために、長い間触れていないいくつかのコードに慣れることで、時間を無駄にしていません。
- 彼らがすでにコードの一部に精通していて、あなたがそうでない場合、フィードバックだけを与えることは、あなたが書くよりも良いコードになるかもしれません。誰かに準備の整ったソリューションを提供すると、多くの場合、それ以上の改善を検討せずに、そのソリューションを使用することになります。
- 常に解決策を提供することは、見劣りするところにあります。あなたは誰かと一緒に働いています、うまくいけば彼らは雇われるのに十分でした。何かが悪い考えである理由を何とかして学ぶことができたら、なぜ彼らはフィードバックを聞いてそれを自分で行うことによってそれを学ばないのですか？
- 常にソリューションを提供するのは奇妙です。あなたが彼らのデスクでペアプログラミングをしていると想像してください：彼らはあなたが素晴らしいと思わないいくつかの行を終えたところです。あなたが見つけたものとその理由を彼らに伝えるだけですか？それとも彼らのキーボードをつかんですぐにあなたのバージョンを見せますか？これは、常にソリューションを提供することで他の人に感じられることです。
- 実際に書く時間を費やすことなく、代わりに何をするかをいつでも言うことができます。質問の最初の問題を説明するとき、あなたはまさにそれをしました。
- 食べ物を配らず、釣り方を教える;）
確かに、特定の代替案を考えている場合がいくつかあり、それを添付する価値があります。しかし、それは私の経験では本当にまれです。 （たくさんのレビュー、大きなプロジェクト）元の作者は、必要な場合はいつでもサンプルを要求できます。
それでも、3番目の理由のため、サンプルを提供するときは、完全なソリューションではなく、たとえば「x.foo()を使用すると、これがより簡単になる」と言って、作成者に記述してもらう価値があります。これにより、時間も節約できます。
レビューをコード化する鍵は、レビューの前にルールについて合意することだと思います。
明確なルールセットがある場合は、ソリューションを提供する必要はありません。ルールが守られていることを確認しているだけです。
代替案の問題が発生するのは、元の開発者がルールに適合する機能を実装する方法を考えられない場合だけです。パフォーマンス要件はあるものの、最適化を何度か試みた後、機能がしきい値よりも長くかかったとします。
しかしながら！ルールが主観的なものである場合「名前は私に承認されなければならない！」その後、はい、あなたは自分でネーマーを任命したばかりで、受け入れ可能な名前のリストのリクエストを期待する必要があります。
継承（オプションのパラメーター）の例はおそらく良いでしょう。長いメソッドと '多すぎる'関数パラメーターを禁止するコードレビュールールを見たことがあるでしょう。しかし、通常、これらは分割することで簡単に解決できます。それは、「このソリューションは複雑すぎるように見えた」部分であり、あなたの客観性が入り込んでおり、おそらく正当化または代替ソリューションが必要です。
可能性のある解決策がすばやく簡単に入力できる場合は、ピアレビューのコメントに含めます。そうでない場合は、少なくとも私の懸念と、その特定のアイテムに問題がある理由を挙げます。あなたがより良いものを考えることができない変数/関数名の場合、私は通常、私にはより良いアイデアがないことを認め、誰かができる場合に備えてコメントを自由回答形式の質問で終了します。そうすれば、誰もより良いオプションを思い付かない場合、レビューは実際に保留されていません。
質問の例として、設計が不十分なクラスを使用しています。やり過ぎかもしれませんが、コードが解決しようとしている問題に対処するにはおそらく継承が最善の方法であり、それはそのままにしておきます。私はそれがショーストッパーではなく、修正するかどうかの開発者の裁量次第であることを示すように表現しようとするでしょう。また、コードのその部分に特に精通していないことの確認を開き、より知識のある開発者やレビュー担当者に、その方法で行われた理由があるかどうかを明確にするよう依頼します。
コードをレビューしている人に話しかけてください。理解するのが少し難しいと感じたことを親しみやすい方法で伝え、それを明確にする方法について話し合います。
書面によるコミュニケーションは、膨大な時間の浪費と、憤りや誤解につながります。
対面、帯域幅ははるかに高く、敵意を防ぐための感情的なサイドチャネルがあります。
その人と実際に話すと、はるかに速くなり、新しい友達を作ることができ、両方ともあなたの仕事をより楽しむことができるかもしれません。