コードレビューを実行する最も効果的な方法は何ですか？
コードレビューを実行するための理想的な方法を見つけたことはありませんが、多くの場合、顧客はそれらを必要としています。お客様ごとにやり方が違うようで、満足したことはありません。
コードレビューを実行する最も効果的な方法は何ですか。
例えば：
- 1人が品質のゲートキーパーと見なされてコードをレビューしていますか、それともチームが標準を所有していますか？
- プロジェクターを使用してチーム演習としてコードをレビューしますか？
- それは、電子メールまたはツールを使用して直接行われますか？
- コードの品質を保証するために、レビューを避け、ペアプログラミングや集団的コード所有権などを使用していますか？
私の仕事では、非常に単純なルールがあります：変更は、トランクへのマージまたはコミットの前に、少なくとも1人の他の開発者によってレビューされる必要があります。私たちの場合、これは、他の人があなたのコンピュータに物理的に座って、変更リストを通過することを意味します。これは完璧なシステムではありませんが、コードの品質は著しく向上しています。
コードがレビューされることがわかっている場合は、最初にコードを見直す必要があります。その後、多くの問題が明らかになります。私たちのシステムでは、レビュアーに何をしたかを説明する必要があります。これにより、以前に見逃した可能性のある問題に再び気づくようになります。また、コード内の何かがレビュー担当者にとってすぐに明確でない場合は、より良い名前、コメント、またはリファクタリングが必要であることを示しています。そしてもちろん、レビュアーも問題を見つけるかもしれません。さらに、変更を確認するだけでなく、レビュー担当者は近くのコードに問題があることに気付く場合もあります。
このシステムには2つの主な欠点があります。変更が些細なものである場合、それを見直しても意味がありません。ただし、変更が「取るに足らない」ものであると宣言されていない場合に、その変更が「些細な」ものであると宣言することの滑りやすい傾斜を避けるために、私たちは絶対に規則に従う必要があります。一方、これは、システムへの大幅な変更や大きな新しいコンポーネントの追加を確認するのに非常に良い方法ではありません。
以前、より正式なレビューを試みました。1人の開発者がレビューするコードをチームの残りのメンバーに電子メールで送信し、その後、チーム全体が集まり、それについて議論しました。これには全員の時間がかかり、その結果、これらのレビューはほとんど行われず、コードベースのごく一部しかレビューされませんでした。 「コミットする前に他の人が変更をレビューする」ことは私たちにとってはるかにうまく機能しました。
苦労するかもしれませんが、コードレビューは好きです。私が彼らを好きな理由は、彼らがコードとより異なる視点にもっと目を向けることです。ペアプログラミングでもコードを見直す必要があると思います。同じコードに取り組んでいる2人の人が、別の目で見逃すことのない同じ間違いをまとめて行うのは簡単です。
プロジェクターを使ってグループで行う場合は、個別に確認する必要がありますbefore会議。そうでなければ、それは単に時間の浪費です。
私はメールとグループでのみコードレビューを行いました。一般的に言って、彼らが直接行うべきではないと思います。誰かがあなたの肩越しに見ていると、コードを突き抜けるようにもう少しプレッシャーを感じます。私は、コードレビュー用に設計されたツールは、ありふれた側面のいくつかに役立ち、コードの問題のある部分にフラグを立てるのが簡単で、電子メールを介するので、良い資産になると思います。
1人ですべてのコードレビューを行う場合の問題は、ボトルネックになる可能性があることです。十分に文書化され、設計されたコーディング標準があれば、必要ありません。環境/リリーススケジュールによっては、誰かを常にスタンバイコードレビューアとして使用することをお勧めします。
この人はコードを理解し、潜在的にゲートキーパーの役割を果たすことができるので、コードの所有権は良い考えだと思います。
SmartBear では コードレビューツール を作成するだけでなく、日常的に使用しています。それは私たちの開発プロセスの不可欠な部分です。チェックインされるすべての変更を確認します。
ゲートキーパーのコードレビュー担当者を1人にするのは、多くの理由で悪い考えです。その人はボトルネックになり、実際に効果を上げるには（プロジェクトを動かし続けるために）コードのレビューをやりすぎなければなりません（一度に60〜90分が効果の限界です）。コードレビューは、アイデアや知識を共有するための優れた方法です。あなたのゲートキーパーがどれほどのスーパースターであっても、彼らはチームの他の人から学ぶことができます。また、全員にコードレビューを行わせると、「コードの共同所有権」環境が生まれます。つまり、人々はコードの品質を所有していると感じます（QAやゲートキーパーだけではありません）。
「 ピアコードレビューのベストプラクティス 」に関する無料のホワイトペーパーに、コードレビューを効果的にするための11のヒントがあります。これの多くは、ジョンがより蒸留された形で述べた本の内容と同じです。
言い訳しない。ペアプログラミングの練習。その可能な最高のコードレビュー。他のメカニズムはすべて非難ゲームになります。ペアプログラミングは、チーム精神と集団的所有権を誘発します。さらに、ペアでアイデアについて議論し、すぐに失敗し、是正措置を講じます。構成管理システム（CMS）にコミットされるのは、コード化されレビューされたペアのみです。幸せなペアプログラミング！
私が参加しているコードレビューでやろうとしていることの1つは、自分でコードをレビューした後、コードの静的分析を行い、Findbugs、PMD、JavaNCCPなどのツールを使用して、これらのツールで見つかった問題を確認することです確認するコード。特に、異常に高いレベルの複雑さを持つものを調べて、なぜそのレベルの複雑さが必要であるか、または提案された脆弱性が重要ではないのかを説明してもらいたいのです。
YMMV
私が現在働いている場所では、重要なインフラストラクチャに接続するハードウェアデバイスとそれらとインターフェイスするソフトウェアを製造しています。したがって、リリース品質に非常に重点を置いています。 Fagan Inspection のバリアントを使用し、正式なレビュープロセスがあります。私たちは、他の認証の中でも、ISO 9001の認証を取得しています。
重要なインフラストラクチャ業界は、信頼性と再現性に非常に関心があります。 :-)
ペアプログラミングを行わない場合は、コードレビューを使用することをお勧めします。
ペアリングの長所と短所を主張するものではありませんが、コードを（少なくとも）他の人が常にレビューすることのプラスの効果に異議を唱えることは困難です。コードは（少なくとも）2人のプログラマーによって書かれ、設計されさえしています-それ以上のものはほとんどありません。私は「少なくとも」と言っています。なぜなら、imoはペアを切り替えることを試みるべきですたくさんだから、誰もがコードの操作に挑戦できます。
私の会社では、ジュニアプログラマー向けの強制的なコードレビューとシニア向けの自主的なレビューを行っています。指定されたコードレビューアは存在せず、レビューリクエストはすべての開発者に送信されます。
このシステムは適切に機能します。レビューは時間の許す限り行われ、変更はいくつかの眼球のセットによってレビューできます。
優れた無料の レビューボード ツールは私たちにとって非常にうまく機能し、レビューを伝達する優れた方法であることが証明されています。
複数の人がコードベースに貢献するプロジェクトに取り組んでいる場合、標準を確立する必要があります。
この時点で、私の経験では、1人の人をコードレビューの「王」として指名し、彼/彼女が言うことを行うのが最善です。この点で、1人のユーザーが標準に準拠していない場合、国王がそれを処理します。
私は開発者として、自分のコードを何度もレビューして、読みやすく、実用的で、その他すべてのものであることを確認しています。通常、コード化する特定の言語でjavadocまたは類似のものを使用し、@ authorタグを使用して、関数やクラスなどに所有権を付加します。
関数が正しくない場合は、クラスと同じように所有者と話します。
私の会社では、各タスクに、タスクをテストするテスターと、コードをレビューするコードレビューアーが割り当てられています。
製品がすでにリリースされていて、何か問題がないことを確認したい場合（ハンドルリークやメモリリークなど）、コードレビューはすばらしいことです。製品をリリースする前の最初の開発では、コードレビューは大変な作業になる可能性があります。
チームにすべての上級開発者がいる場合でも、ピアレビューは役に立ちます。誰もが時々間違いを犯します。チームにシニアとジュニアが何人かいる場合は、シニア開発者にコードレビューを依頼しますが、シニアのコードのコードレビューも残します。
コードレビューの重要な点の1つは、発生したエラーをキャッチできることですが、テストの代わりにはなりません。
コードのレビューを行う最も効果的な方法は、ブランチの違いを示すためにgithubを使用して1対1で行うことです。
1人が品質のゲートキーパーと見なされてコードをレビューしていますか、それともチームが標準を所有していますか？
- チームの規模によって異なります。3人のチームには、優れた実践について最高の知識を持つ1人のシニアがいますが、12人のチームには、その役割を果たす3人または4人のチームがいます。
プロジェクターを使用してチーム演習としてコードをレビューしますか？
- 直接。脅威を減らすために1対1。時々、知識の広がりのために、共同のエリアで行われます。正確な状況、人、時刻表などによって異なります。
それは、電子メールまたはツールを使用して直接行われますか？
- 直接。私たちはgitとgithubを使用しており、コードレビューを容易にする優れたコードレビューツールと比較ツールを備えています。
コードの品質を保証するために、レビューを避け、ペアプログラミングや集団的コード所有権などを使用していますか？
- 必要に応じて両方を行うようにしています。つまり、特に厄介な問題に直面したとき、またはコアインフラストラクチャで作業しているとき、または休暇の準備や会社を辞めるときに、ペアリングを行って知識を共有および転送することができます。ほとんどのコードまたは表面的な変更以上のものがあるコードも最後に確認する必要があります。
すべてのコーディング項目と同様に、正しい答えは考慮に入れるべきです：
- 会社のタイプ（スタートアップ企業と大企業など）
- 会社の規模
- 開発者の数
- 予算
- 時間枠
- ワークロード
- コードの複雑さ
- 査読者の能力
- レビューアの可用性
私の会社では、非常に重要なプロダクションを変更して標準のQAプロセスを実行する時間がない限り、チェックイン前に正式なコードレビューを行うことはありません。
コードレビューが役立つと感じるたびに、変更したコードに「// todo：code review by joe」というコメントを追加します。通常、 Joeは変更されたコードを所有しているため選択しますが、この選択基準が適用されない場合（通常は適用されます）、ランダムに他のユーザーを選択します。そしてもちろん、Joeがその時点でたまたま利用できる場合は、古き良きショルダーレビュー方式を使用します。
レビュアーとして行う必要があるのは、コード全体を定期的に「// todo：code review by me」で定期的に検索し、変更を確認して、コードをチェックすることだけです。 「todo ...」コメントなしで
問題がある場合は、従来の通信方法（メール/チャット/その他）に切り替えます。
この方法は、レビューシステムに求めている2つの主要な特性を提供します。
- 非常に軽い頭上
- トレーサビリティ
私は多くの企業で働いており、多くのプロセスを見てきました。私の現在のチームは、これまでに見た中でこれを最もよく処理しています。
私たちはアジャイル開発プロセスを使用しており、その一部として、各ストーリーが通過しなければならないゲートがあります。それらのゲートの1つはコードレビューです。ストーリーは、コードレビューが完了するまでテストに移行しません。
さらに、コードをgithub.comに保存します。そのため、開発者が変更を終えた後、ストーリーへのコミットへのリンクを投稿します。
次に、レビューする同僚の開発者にタグを付けます。 Githubには、誰かが問題のコード行に直接コメントできるコメントシステムがあります。その後、Githubからディストリビューションにメールが送信されるため、他のチームから目が離せない場合があります。
このプロセスは私たちにとって非常にうまく機能しています。私たちは、コミットの投稿を容易にし、コミュニケーションを容易にするアジャイルプロセスツールを使用しています。
問題が特に厄介な場合は、座って話し合います。これは私たちのプロセスに不可欠であり、プロセスがどのように機能するかについて誰もが賛同しているため、機能します。コードレビューの結果、やり直しが必要な場合は、チケットを進行中の状態に戻すことができます。変更を加えた後、再度レビューすることもできます。または、レビュー担当者は、アイテムの修正で十分であり、再度レビューする必要がないことをストーリーに記します。
テストで問題が発生した場合は、進行中の状態に戻り、それ以降の変更もすべて確認されます。