ピア/コードレビューの不満

私は自分自身をスーパースター開発者とは呼びませんが、比較的経験豊富な開発者です。私はコードの品質を高いレベルに保ち、コーディングスタイルを常に改善し、コードを効率的で読みやすく、一貫性のあるものにするよう努めています。また、品質と速度の両方のバランスが必要であることも理解しています。

これを達成するために、ピアレビューの概念をチームに導入しました。github pull-requestでのマージの2つの親指。素晴らしい-しかし、私の意見では、せきをせずに。

同じ同僚からのピアレビューコメントがよく見られます-

• 後にスペースを追加すると良いでしょう <INSERT SOMETHING HERE>
• メソッド間の不要な余分な行
• docblock内のコメントの最後で完全停止を使用する必要があります。

今、私の観点から-レビュー担当者はコードの美学を表面的に見ており-実際にコードレビューを行っていません。化粧品のコードレビューは、ar慢/エリートのメンタリティとして私に伝わります。内容はありませんが、レビュアーが技術的に正しいため、あまり議論することはできません。上記の種類のレビューはもっと少なく、次のようなレビューをもっと見たいです。

• 循環的な複雑さを減らすには...
• 早く終了し、if / elseを避ける
• DBクエリをリポジトリに抽象化します
• このロジックは実際にはここには属していません
• 繰り返してはいけません-抽象と再利用
• Xメソッドの引数として渡された場合はどうなりYますか？
• これの単体テストはどこにありますか？

私は、化粧品の種類のレビューを与えるのは常に同じ種類の人々であり、私の意見では「品質と論理に基づく」ピアレビューを与えるのは同じ種類の人々であると思います。

ピアレビューの正しいアプローチは（もしあれば）何ですか。そして、同じ人が基本的にコードをスキミングして、実際のコードの欠陥ではなくスペルミスや美的欠陥を探すことにイライラするのは正しいですか？

私が正しい場合-化粧品の修正を提案することとのバランスで、同僚に実際にコードの欠陥を探すように奨励するにはどうすればよいですか？

私が間違っている場合-私を啓発してください。実際に優れたコードレビューを構成するものについて、経験則はありますか？コードレビューとは何かという点を見逃していませんか？

私の観点から言うと、コードレビューはコードの責任を共有することです。ロジック、読みやすさ、機能性をアドレッシング/チェックせずに、コードを評価するのは気が進まないでしょう。また、誰かがdoc-blockの完全な停止を省略したことに気付いたとしても、コードの強固な部分のマージをブロックすることはありません。

コードを確認するとき、500 Locあたり15〜45分かかります。これらの浅いレビューが実行しているレビューの深さであれば、これまで10分以上かかることは想像できません。さらに、浅いレビュアーからの評価はどれくらいの価値がありますか？確かに、これはすべての親指の重さが等しくないことを意味し、2パスのレビュープロセスが必要になる可能性があります。深いレビューのための1つの親指と「研磨」のための2番目の親指？

レビューの種類

ピアレビューを行う真の方法はありません。コードの品質が十分に高いかどうかを判断する方法はたくさんあります。明らかにバグがあるのか​​、それともスケーリングされないソリューションや脆弱なソリューションがあるのか​​という問題があります。地域の標準やガイドラインへの適合の問題は、おそらく他のいくつかのものほど重要ではありませんが、高品質のコードに寄与するものの一部でもあります。

レビュアーの種類

ソフトウェアを判断するための基準が異なるように、判断を行う人も異なります。私たちは皆、自分のスキルと好みを持っています。他の人がメモリ使用量やテストのコードカバレッジなどに関心があるのと同様に、一部の人はローカル標準に従うことが非常に重要であると考えるかもしれません。全体としてより良いコードを書くのに役立つので、これらの種類のレビューがすべて必要です。

ピアレビューはコラボレーションであり、タグのゲームではありません

あなたが彼らに彼らの仕事をする方法を伝える権利があるかどうかはわかりません。確実に別の方法で知っている場合を除き、この人は自分が適切だと思う方法に貢献しようとしていると想定してください。ただし、改善の余地がある場合、またはピアレビューで期待されることを理解していないと思われる場合は、彼らに相談してください。

ピアレビューのポイントは、あなたのピアを巻き込むことです。関与とは、コードを壁に投げて、応答が返されるのを待つことではありません。関与は、より良いコードを作成するために協力しています。彼らと会話をします。

助言

あなたが書いたあなたの質問の終わりに向かって：

明白な美的エラーとのバランスで、コードの欠陥を実際に探すように同僚を励ますにはどうすればいいですか？

繰り返しますが、答えはコミュニケーションです。おそらく、あなたは彼らに尋ねることができます。「ねえ、これらの間違いを見つけてくれて感謝しています。コードを適切に構造化しているかどうかなど、より深い問題にも集中できたら、とても助かります。助けて。"

より実用的な注意として、私は個人的にコードレビューのコメントを2つのキャンプに分け、それらを適切に表現します。修正が必要なものと、より見栄えの良いものです。ファイルの最後に空白行が多すぎる場合、しっかりした、動作中のコードがチェックインされるのを決して防ぎません。ただし、それを指摘しますが、「私たちのガイドラインでは、最後に1つの空白行があると言います。20行あります。これはショーストッパーではありませんが、チャンスがあれば、修正したいかもしれません」。

考慮すべきことは他にもあります。コードの浅いレビューを行うのは、あなたを苦しめるかもしれません。彼らの最大の目的は、あなた（または同様のレビューを受ける他のチームメイト）があなた自身の組織のコーディング標準に関してだらしないことである可能性が非常に高いかもしれません。

レビュー後の対処

そして最後に、レビュー後のちょっとしたアドバイス：レビュー後にコードをコミットするときは、1つのコミットですべての表面的なことを処理し、別のコミットでは機能的な変更を処理することを検討します。2つを混ぜると、重要な変更を重要でない変更と区別するのが難しくなります。すべての化粧品の変更を行い、「化粧品;機能的な変更はありません」などのメッセージでコミットします。

人々はコードのフォーマットとタイプミスについてコメントします。なぜなら、それらは見つけやすく、彼らからの多くの努力を必要としないからです。

この部分は簡単に修正できます。ほとんどの言語にはリンターまたはスタイルチェッカーツールがあります。ビルドプロセスでプラグインし、冗長なスペースがある場合にビルドが失敗するようにします。その結果、コメントするスタイルの問題はありません。

彼らに本当の問題を見つけさせるのはかなり難しいかもしれません。これには、好奇心and盛で詳細志向の特別な考え方だけでなく、大きな動機付けも必要です。

そして、この動機は経験から来ています。以前の開発者によって書かれた安っぽいコードを使用しようとした経験。上級エンジニアにはたくさんあります。たわごとの海で泳ぐことは、あなたが再びそこに着かないようにあなたにかなりの欲求を与えます。

コードレビュー中にチェックする主なものを1つ選択する必要がある場合、それはコードの保守性です。常に、このコードをレビューする開発者はそれを理解し、それを強化および変更する準備ができている必要があります。ここで何が起こっているのかわからない場合は、すぐにそれを伝える必要があり、コードを書き直す必要があります。

実用的な答えは次のとおりです。

シナリオ1：あなたは上級メンバーであり、練習を決定できる人です

会議を呼び出し、コードレビューのルールとガイドラインをレイアウトします。私を信じて、明確なガイドラインは「名誉」システムやトレーニングよりもうまく機能します。コードのフォーマットの問題がまったく発生してはならないことを明確にしてください。一部のメンバーは反対します。それらに耳を傾け、最初の数か月間は実験としてガイドラインに従うように依頼します。現在のガイドラインが機能しない場合は、変更する意欲を示します。

シナリオ2：練習を決定する人ではないか、チームの比較的後輩のメンバーである

最善の策は、シナリオ1に到達するまでコードレビューの問題を解決することです。

「些細な」コードレビューコメントを防ぐための簡単な答えは、（効率のために）レビューアがそれらを修正するべきだと主張することです。したがって、レビュアーが、あなたが（ホラー！）フルストップを逃したか、間違ったコメントをつづったことに気付いた場合、彼らはそれを修正して先に進むべきです。

私の経験では、これは次のことを意味します。

• レビュー担当者は、これらの比較的無意味なレビューコメントを作成し、修正するためにそれらを戻すことを停止します。
• ほとんどのOCDレビュー担当者のみがそれらを修正します。つまり、ほとんどのレビューが合格します。これには、開発者がより実質的なレビューを行う必要があるというノックオン効果があります。実際にコードをレビューしていないためにトリビアを報告するものは、すべてのレビューがコメントなしで合格する理由を正当化する必要があります。

いずれにせよ、これは利点です。失敗したレビューのコストは、開発者に作業中の作業を停止させ、コードを再訪させ、その後のフォローアップレビューを行うという点で高くなります。レビューで実際のコードの品質やアーキテクチャの問題が見つかった場合、このコストは1ペニーの価値がありますが、トリビアにこのコストを支払う価値はありません。

レビュープロセスを確認する

コードレビューに加えて、レビュープロセスも定期的にレビューすることをお勧めします。ここでは、適切なコードレビューを行う方法など、多くのことを学ぶことができます。

通常、バイクシェッダーの一部は経験の浅いだけで、何を探すべきかわからないだけです。彼らは彼らのコードに関してだけでなく、役に立つコードレビューを行うことに関しても少しのガイダンスを必要とします。レビューについてのフィードバックを提供すると、学習プロセスにつながり、（希望に満ちた）レビューとコードの改善につながります。

次に、一連の値と基準、組織またはチームがGood Code™として認識しているもの、および回避すべきアンチパターンを（大まかに）形式化することをお勧めします。sthを設定することではありません。具体的には、最初からコードの品質について共通のコンセンサスを得ることについて。

これの両側にいる人として（他の人が書いたコードをレビューし、私が書いたコードをレビューしている）、フィードバックは3つのカテゴリに分類されると思います。まあ、4、「すべてが順調」という楽しいケースもあります。

「いいだろうが、それはあなたをブロックしません」（すべてのフィードバックがこのカテゴリに該当する場合、私は「あなたがそれらを修正することを言わない限り、XX：XXでマージします」とマージ要求を送信することがあります、または「システムがスローするブロックが無効になっていることを確認してください」）：

• 文の終わりで完全に停止することを忘れます（ドキュメント文字列またはコメントで）。形や形式を問わずユーザーに送信されないものの不格好な文法（再び、ドキュメント文字列とコメント）
• よりエレガントな方法を備えたコードですが、理解可能で慣用的なものがあります（おそらく提案を入れることもあるので、そのままにしておくか修正するのは簡単です）

「修正する必要があるが、それを行うことを信頼する」（すべてのことがこのカテゴリまたは前のカテゴリに該当する場合は、「これらを修正し、あなたがあなたに言ったらマージします」と応答します」再完了」（そして、その時点で私はおそらくすぐにスキャンして、他に何もポップアップしないことを確認します）：

• 些細な問題（「ブール値をtrueに比較している、それはちょっと妄想的だ...」、...）
• 軽度のスタイル違反（「スタイルガイドにはXと書かれていますが、これまでは何もしていませんでした。行きたい方法に応じてYまたはZを行います」）
• 書くのが難しくないはずのいくつかの欠落したテストケース

そして最後に、「問題のあるもの、これらの問題を修正したらコードを再度確認する必要があります」（このカテゴリに何かがある場合は、もう一度レビューする必要があるので、「また、いくつかのマイナーなものがあります。最初の2つのカテゴリのいずれかが存在する場合は、それらの一部が修正されているのを確認してください」

• これは、「いいえ、それを書くのに本当に良い方法があります」、「ユニットテストがこれらのエッジケースを逃すので、あなたが期待するものを計算していません」と他のすべての深刻な問題です。

一部の人々は最も重要な質問を忘れているようです：コードレビューで実際に達成したいことは何ですか？

コードレビューの目的は、バグのない保守可能なコードをより迅速に取得することです。コードレビューは、いくつかの方法でこれを達成します：開発者は、レビューされることを知っているため、そもそもより良いコードを書く、レビュープロセスの一部として知識が共有される、レビューアが開発者としての自分の間違いを盲目にしないのでバグが見つかるすることができます。

レビュープロセスを同僚を倒したり、同僚のために作品を作成したりする機会とみなす場合、それは間違っています。