コードレビューを実行する最も効果的な方法は何ですか？[閉まっている]

コードレビューを実行する理想的な方法を見つけたことがありませんが、多くの場合、顧客はそれらを必要とします。各顧客は異なる方法でそれらを行うようであり、私はそれらのいずれにも満足感を感じたことはありません。

コードレビューを行うための最も効果的な方法は何ですか？

例えば：

• 1人が品質の門番と見なされ、コードをレビューしていますか、それともチームが標準を所有していますか？
• プロジェクターを使用してチームの練習としてコードをレビューしますか？
• 直接、メール、またはツールを使用して行われますか？
• コードの品質を確保するために、ペアプログラミングや集合的なコード所有権などのレビューを避けて使用していますか？

私の仕事では、非常に単純なルールがあります：トランクへのマージまたはコミットの前に、少なくとも1人の他の開発者が変更をレビューする必要があります。私たちの場合、これは他の人が物理的にあなたのコンピューターに座って、変更リストを通過することを意味します。これは完璧なシステムではありませんが、それでもコード品質が著しく改善されています。

コードがレビューされることがわかっている場合は、最初にコードを確認する必要があります。その後、多くの問題が明らかになります。私たちのシステムでは、あなたが何をしたかをレビュアーに説明する必要があります。また、コード内の何かがレビュアーにすぐに明確にならない場合は、より良い名前、コメント、またはリファクタリングが必要であることを示す良い兆候です。そして、もちろん、レビュアーも問題を見つけるかもしれません。さらに、変更を確認することに加えて、レビュー担当者は近くのコードの問題に気付く場合があります。

このシステムには2つの主な欠点があります。変更が些細な場合は、レビューすることはほとんど意味がありません。ただし、変更が「些細」であると宣言するという滑りやすい勾配を避けるために、絶対に規則に従う必要があります。一方、これは、システムの大幅な変更や大規模な新しいコンポーネントの追加を確認するのにあまり良い方法ではありません。

1人の開発者がコードをメールでチームの他のメンバーにレビューし、その後チーム全体が集まって議論するという、以前より正式なレビューを試みました。これにはすべての人の時間がかかり、その結果、これらのレビューはほとんど行われず、コードベースのほんの一部がレビューされました。「コミットする前に他の人が変更をレビューする」ことは、私たちにとってずっとうまくいきました。

私はコードレビューが好きですが、それらは苦痛になる可能性があります。私が彼らを好きな理由は、彼らがコードと異なる視点にもっと目を向けるからです。ペアプログラミングでも、コードをレビューする必要があると思います。同じコードで作業している2人の人が、異なる目が見逃さないかもしれない同じミスをまとめて犯すのは簡単です。

プロジェクターを使用してグループで行う場合、会議の前に個別に確認する必要があります。それ以外の場合、それは時間の浪費です。

メールとグループでコードレビューを行っただけです。一般的に言って、私はそれらが直接行われるべきではないと思います。誰かがあなたの肩越しに見ていると、コードを急ぐようにもう少しプレッシャーを感じます。コードレビュー用に設計されたツールは、ありふれた側面の一部に役立ち、電子メールよりも問題のあるコードのフラグを立てやすくするため、良い資産になると信じています。

1人ですべてのコードレビューを行うことの問題は、ボトルネックになる可能性があることです。十分に文書化され、設計されたコーディング標準があれば、それは必要ないはずです。環境/リリーススケジュールによっては、常に誰かをスタンバイコードレビュアーにすることをお勧めします。

この人はコードを理解し、潜在的にゲートキーパーの役割を果たすことが優先されるため、コードの所有権は良い考えだと思います。

SmartBearでは、コードレビューツールを作成するだけでなく、日常的にも使用しています。これは開発プロセスの重要な部分です。チェックインされるすべての変更を確認します。

多くの理由から、ゲートキーパーのコードレビューアを1人にするのは悪い考えだと思います。その人はボトルネックになり、実際に効果的であるためには（プロジェクトを動かし続けるために）コードレビューをしすぎなければなりません（一度に60-90分が効果の限界です）。コードレビューは、アイデアや知識を共有するための優れた方法です。ゲートキーパーがどれだけスーパースターであっても、チームの他のメンバーから学ぶことができます。また、全員にコードレビューを行わせることで、コードの品質（QAやゲートキーパーだけではない）を所有していると人々が感じる「集団コード所有権」環境も作成されます。

「ピアコードレビューのベストプラクティス」に関する無料のホワイトペーパーがあり、コードレビューを効果的にするための11のヒントがあります。これの多くは、ジョンがより蒸留された形で言及した本の内容と同じです。

言い訳しない。ペアプログラミングを練習します。可能な限り最高のコードレビュー。その他のメカニズムは、ゲームのせいになります。ペアプログラミングは、チームスピリットと集団所有権を誘導します。さらに、ペアでアイデアを議論し、迅速に失敗し、修正アクションを実行します。構成管理システム（CMS）にコミットされるのは、コード化されレビューされたコードのみです。ハッピーペアプログラミング！

複数の人がコードベースに貢献するプロジェクトに取り組んでいる場合、標準を確立する必要があります。

この時点で、私の経験では、1人をコードレビューの「王」として指定するのが最善です。この点で、1人のユーザーが標準を順守していない場合、王がそれを処理します。

開発者として、私は自分のコードを何度も見直し、読みやすく、賢明なもの、その他すべてのものを探します。通常、コードを作成する特定の言語ではjavadocなどを使用し、@ authorタグを使用して関数、クラスなどに所有権を割り当てます。

関数が正しくない場合、クラスなどと同じように、所有者と話します。

私の会社では、各タスクにタスクをテストするためのテスターと、コードをレビューするためのコードレビューアーが割り当てられています。

製品がすでにリリースされていて、ハンドルリークやメモリリークなど、何も間違っていないことを確認したい場合、コードレビューは素晴らしいことです。製品をリリースする前の初期開発中に、コードレビューが大変な作業になると思います。

チームにすべての上級開発者がいる場合、ピアレビューは依然として有用です。誰もが時々間違いを犯します。チームに上級者と後輩がいる場合は、上級開発者にコードレビューを行わせますが、上級者のコードのコードレビューも同様に行います。

コードレビューの重要な点の1つは、私たちが犯したエラーをキャッチできることですが、テストに代わるものではありません。

ペアプログラミングを行っていない場合は、コードレビューを使用することをお勧めします。

ペアリングの長所と短所を論ずることはできませんが、コードを（少なくとも）他の人が絶えずレビューすることのプラスの効果に異議を唱えることは困難です。コードは（少なくとも）2人のプログラマーによって作成および設計されています。それ以上の改善はほとんどありません。私は「少なくとも」と言っています。なぜなら、誰もがコードを操作するためのショットを得るために、ペアを頻繁に切り替えてみるべきだからです。

私が参加しているコードレビューでやろうとしていることの1つは、自分でコードをレビューした後、Findbugs、PMD、JavaNCCPなどのツールを使用してコードの静的分析を行い、これらのツールで見つかった問題を調べることですレビューするコード。特に、異常に高いレベルの複雑さがあるものを見て、なぜそのレベルの複雑さが必要なのか、または提案された脆弱性が重要ではないのかを説明したいと考えています。

YMMV

私が現在働いている場所では、重要なインフラストラクチャーに入るハードウェアデバイスとそれらとインターフェースするソフトウェアを製造しています。したがって、リリースの品質に非常に重点を置いています。Fagan Inspectionのバリアントを使用し、正式なレビュープロセスを実施しています。他の認証の中でも、ISO 9001認証を取得しています。

重要なインフラストラクチャ業界は、信頼性と再現性に非常に興味を持っています。:-)

私の会社では、ジュニアプログラマー向けの強制的なコードレビューと、シニア向けの自主的なレビューを行っています。指定されたコードレビューアはなく、レビューリクエストはすべての開発者に送信されます。

このシステムはうまく機能します。時間の許す限りレビューが行われ、変更はいくつかの眼球セットでレビューできます。

優れた無料のレビューボードツールは、私たちにとって非常にうまく機能し、レビューを伝える優れた方法であることが証明されています。

私の会社では、チェックインの前に正式なコードレビューを行うことはありません。ただし、非常に重要なプロダクションを変更し、標準のQAプロセスを実行する時間がない場合を除きます。

私たちがしていることは、コードレビューが有用だと思うたびに、変更されたコードに「// todo：joeによるコードレビュー」コメントを追加するということです。通常、Joeは変更されたコードを所有しているため選択しますが、この選択基準が適用されない（通常は適用される）場合は、ランダムに他の誰かを選択します。そしてもちろん、そのときにJoeがたまたま利用できるのであれば、古き良き復習方法を使用します。

レビューアとして、あなたがしなければならない唯一のことは、定期的に「// todo：code review by me」のコード全体を検索し、変更をレビューし、「todo ...」コメントなしでコードをチェックインすることです。

問題がある場合は、従来の通信方法（mail / chat / etc）に戻ります。

この方法は、レビューシステムに求めている2つの主な特性を提供します。

• 非常に軽いオーバーヘッド
• トレーサビリティ

コードのレビューを行う最も効果的な方法は、ブランチの違いを示すためにgithubを使用して1対1にすることです。

• 1人が品質の門番と見なされ、コードをレビューしていますか、それともチームが標準を所有していますか？

  • チームの規模に依存します-3人のチームには、優れた実践に関する最高の知識を持つ1人のシニアがいますが、12人のチームには、その役割を果たす3人または4人の人がいます。

• プロジェクターを使用してチームの練習としてコードをレビューしますか？

  • 直接。1対1で脅威を軽減します。時には知識の普及のために、共同エリアで行われます。正確な状況、人、時刻表などに依存します

• 直接、メール、またはツールを使用して行われますか？

  • 直接。gitとgithubを使用しており、コードレビューを容易にする優れたコードレビューと差分比較ツールを備えています。

• コードの品質を確保するために、ペアプログラミングや集合的なコード所有権などのレビューを避けて使用していますか？

  • 必要に応じて両方を試みます。つまり、特に厄介な問題に巻き込まれたとき、またはコアインフラストラクチャで作業しているとき、休暇の準備や会社を辞めたときに、ペアリングを行って知識を共有および伝達することができます。ほとんどのコードまたは表面的な変更以外のコードは、最後に確認する必要があります。

すべてのコーディング項目と同様に、正しい答えは考慮に入れる必要があります。

• 会社のタイプ（例：スタートアップと大企業）
• 会社の規模
• 開発者の数
• 予算
• 時間枠
• 仕事量
• コードの複雑さ
• レビューアの能力
• レビューアの可用性

私は多くの企業で働き、多くのプロセスを見てきました。私の現在のチームは、これまで見てきた中でこれを最高に処理します。

アジャイル開発プロセスを使用し、その一環として、各ストーリーを通過するゲートがあります。それらのゲートの1つはコードレビューです。コードのレビューが完了するまで、ストーリーはテストに移行しません。

さらに、github.comにコードを保存します。そのため、開発者が変更を完了した後、ストーリーへのコミットへのリンクを投稿します。

次に、レビューする仲間の開発者にタグを付けます。Githubにはコメントシステムがあり、誰かが問題のコード行にコメントすることができます。次に、Githubがディストリビューションにメールを送信するため、実際に他のチームの一部から実際に余分な目を引くことがあります。

このプロセスは非常にうまく機能しました。コミットを簡単に投稿できるだけでなく、コミュニケーションを促進するアジャイルプロセスツールを使用します。

問題が特に厄介な場合は、座って議論します。これは私たちのプロセスに不可欠であり、誰もがプロセスの仕組みに賛同しているためです。コードレビューの結果、必要な再作業が必要な場合はチケットを進行中に戻すことができます。変更が行われた後、再度レビューすることができます。また、レビューアーは、アイテムを修正するだけで十分であり、再度レビューする必要がないというストーリーに気付く場合があります。

テストが何かを元に戻す場合、それは進行中に戻り、さらなる変更もレビューされます。