すべてのコードをレビューする必要がありますか？

私たちは現在、開発プロセスを修正しており、コミットの100％をピアレビュー済みにしておくべきかどうか疑問に思っています。

コードレビューに関するあなたの経験は何ですか？

• あなたはそれらに「多くの」時間を費やす傾向がありますか（1日あたり1/2時間と言ってください）、それとも最大5/10分のスキムオーバーですか？
• 1日/週/スプリント/プロジェクトごとに費やす時間は決まっていますか？
• 最も重要なことは、コードの100％がピアレビューされることを目標とすべきか、または100％が必要ではないと思いますか？

各ストーリーには「コードレビュー」タスクがあります。理想的には、そのストーリーの開発に関与していない人が、そのストーリーに関連するすべてのコード変更をレビューします。うまくいきます。

多くの時間？大したことではなく、コードの量に依存します-明らかなエラー、タイプミス、基本的なロジックの健全性チェック、キャッチされていない例外などを探しています。

これはバグを見つけるための質の高いステップであるため、ある程度の価値があります。時間の割り当てはそれを行う最善の方法ではないかもしれません-何かがかなり複雑な場合は、コードレビューする必要がありますか？

ところで、他の誰かがコードのレビューを行うことが重要です。

コードがどれだけレビューでカバーされているかというより重要な問題は、レビューの効果です。レビューで問題がほとんどまたはまったく発見されない場合、完全なカバレッジに到達しても役に立たないでしょう。

レビューをより効果的にするための最初の作業を行ってから、カバレッジを決定します。

レビューは、コード上だけでなく、設計上でも実行する必要があります。

また、レビューはテストとツールの代わりにはなりません。

• レビューでコードを実行できない
• レビューにはコード分析を含めることができます
• 再利用と読みやすさを検討するレビュー
• レビューは効率のいくつかの側面を調べることができますが、これは実行時間の実際の測定とボトルネックの発見に代わるものではありません
• 静的コード分析のためのツールがあります
• コーディング規約をテストするためのツールがありますが、レビュー時間を無駄にしないでください
• ユニット、システム、および統合テストのウェットランコード
• ユニット、システム、および統合テストのテストは自動的に繰り返すことができ、コードレビューは通常1回限りです
• 単体テストは、高いコードカバレッジを持ち、主要な成功シナリオと終了条件の両方をテストする必要があります。コードレビューではこれを部分的にしか実行できません
• 統合テストでは、ユニットまたはシステムが連携して機能するかどうかをテストします。コードレビューではこれを置き換えることはできません
• システムテストはシステム全体の機能をテストします。コードレビューはこれを置き換えることはできません

レビューのために、1か月（またはスプリントごと）に事前に設定した時間を割り当ててみてください。次のようなヒューリスティックを使用して、次の専用スロットでレビューするコードを選択します。

• 報告された未確認のバグを含む可能性のあるコード
• 最近のコードにはバグが特定されています
• パフォーマンスの問題があるコード（ボトルネック）
• 新しい開発者によって書かれたコード
• 以前に慣れていない人によって最近更新されたレガシーコード
• 新しい領域のコード
• 新しい開発者に学習してほしい既存のコード
• 複雑な問題を解決するコード
• 分析ツールによって複雑であると識別されたコード

また、作成者ではなくコード（または設計やテスト）をレビューしていることに注意してください。

次の資料をお勧めします。

選択的ホームワークレスレビュー
ピアコードレビューのベストキープシークレット

場合によります。

それはあなたのソフトウェアが何をしているかに依存します：

• それが電子ペースメーカーまたはスペースシャトルを制御する場合、間違いなくはい。

• それが使い捨てのプロトタイプである場合、おそらくそうではありません。

それはまた、あなたがどれだけリソースを持っているか、開発者がどれだけ経験があるか、そしてコードレビューで何を探しているかにも依存します。（他の人のコードをレビューする平均的な開発者は、おそらくスタイルの問題に気付き、微妙なアルゴリズムのバグを見逃すことになることを覚えておいてください...特にコードのレビューが面倒なことを考えると）

私のアドバイスは、正確性が重要であり、検出されないエラーのコストが高いコードのコードレビュー作業を節約することです。

まず、この質問に答える必要があります。 なぜコードをレビューするのですか？

その答えを手にすれば、どのコードをレビューする必要があるかがわかります。

一部のコードレビューは、テストが行​​うこと、または行うことを正確に達成します。それがレビューの目標である場合、テストが少ない場合は100％に近づけることをお勧めします。ただし、テストツールにこれを行わせると、すべてのコードをレビューする必要が減ります。

優れたレビューのほとんどは、知識を共有し、レビューの開発者（コードを作成した人またはコードをレビューする人）の能力を高めることに焦点を当てているようです。これがレビューの主な理由であるため、コードの100％をレビューすることはおそらくやり過ぎです。

完全な世界では、要件仕様からユーザーマニュアル、テストケースまで、少なくとも1人の他の人によってレビューされた著者とピアによってすべてが明示的に読み取られます。しかし、レビュー、さらには単純なデスクチェックでも、時間と費用がかかります。これは、レビューする対象とレビューする時期を選択する必要があることを意味します。

レビューするものに優先順位を付け、レビュー方法を選択し、適切な詳細レベルでできる限りレビューすることをお勧めします。優先順位付けは、要件のレビュー、設計および生産コードのレビュー、テストケースのレビューなど、成果物の種類に基づいて行うことができます。その中で、高リスクまたは高価値のコンポーネントをレビューの優先順位、またはおそらくより正式なレビューを受けるように指定することもできます。

時間に関しては、すべてコンポーネントの優先度に戻ります。レビューに10〜15分を費やしたり、複数の人が個別にコードを読んだり、部屋に行って30〜45分続くより正式な検査プロセスを行ったりすることがありました（サイズによって異なります）モジュール）。

最終的には、時間、コスト、範囲、品質のバランスです。すべてを使用することはできないため、できる限り最適化する必要があります。

提案として、レビューを行う予定がある場合は、レビューがチームメンバー間で不必要な摩擦を引き起こさないように、レビューの範囲と目標に関するガイドラインを共有してください。

首尾一貫したチームはより良いプロジェクトを構築します。人々は、ナンセンスまたは完璧な要求に対して関係を失う可能性があります。こういうことで文句を言ったり、他の人にバグを起こしたりする人は、いつもそのような人です...

ピアレビューを行うために1日1時間予約しますが、必ずしも必要ではありません。コードベースは、数十の製品で共有されています。私たちのポリシーでは、ある製品に固有のコードの些細な変更は、レビューなしでチェックインしても問題ありません。より複雑な単一製品の変更にはレビューが必要ですが、同僚に電話をかけてもう一度やり直すのと同じくらい非公式かもしれません。共有コードの変更には、他の製品の開発者を含む、より正式なレビューが必要です。私たちのポリシーは、私が働いてきた他の会社と比較して、かなり良いバランスを取っていると思います。

私は、中心的な役割が少ない同僚の何人かよりも1日あたりレビューに多くの時間を費やしていますが、レビューポリシーの前に、開発者がバグを追跡するよりも多くの時間を簡単に無駄にする可能性があるため、不当な時間とは考えていません導入された別の製品に。

コードのレビューは100％完了しました。テスト、特に100％コードカバレッジテストよりもはるかに安価です。私たちはそれらにあまり時間を費やさないので、1日1時間以上のレビューは生産性が低下します。（30分はそれほど多くありません）。

プロセスをゼロ化するときは、メモを残してください。あなたは何を見つけましたか？QAは後で何を見つけましたか？顧客は何を見つけましたか？なぜこれらのバグがあなたを逃れたのですか？

実装に関するアイデアをチームで構築して共有するために、主に定期的なコードレビューを行います。この方法で同僚から多くを学ぶことができます。

チェックインごとにピアコードのレビューが必要です。ピアがいない場合、チェックイン後のレビューを手配します。レビューアは、ソース管理チェックインコメントに記載されています。

これらは多くの時間を要しません、そして、彼らは仲間の間で行われるので、彼らに有毒な大人子の側面がありません。

IMOでは、コードレビューが必要です。あなたは99.999 ...％の確率で常に正しいとは限らないため、正しいことを確認する必要があります。時間が設定されていますか？いいえ。しかし、時間をかけてコードを確認します。通常、同僚に同じことをさせます。

コードレビューは困難に思えるかもしれませんが、適切に行われた場合、貴重なツールです。これらは、設計および実装のミスに対する最初の防御線になります。配置したすべての機能のコードレビューを実施していない場合は、できるだけ早く開始する必要があります。

ピアレビューに費やす時間については、コードレビューの実施と対応のために、推定開発時間全体の5〜10％を残すことをお勧めします。

効果的なコードレビューを実施するためのホワイトペーパーがあります。順を追ったガイドであり、直面する可能性のある一般的な落とし穴とその解決方法について説明します。当社のウェブサイトからダウンロードできます。