コードレビュー

コードレビュー（ピアレビューとも呼ばれる）は、実装後または実装の中断中に、主にソースコードの一部を表示および読み取り、 1人または複数人がプログラムをチェックするソフトウェア品質保証活動です。少なくとも1人はコードの作成者であってはなりません。作成者を除くチェックを実行する人は「レビュアー」と呼ばれます。^{[1] [2]}

品質問題の直接的な発見が主な目的となることが多いが、^[3]コードレビューは通常、以下の目的の組み合わせを達成するために実行される: ^{[4] [5]}

• コード品質の向上 - 内部コードの品質と保守性（読みやすさ、統一性、理解しやすさなど）を向上
• 欠陥の発見 - 外部的な側面、特に正確性に関する品質を向上させるだけでなく、パフォーマンスの問題、セキュリティの脆弱性、マルウェアの挿入などの問題も発見します。
• 学習/知識の伝達 – コードベースの知識、ソリューションのアプローチ、品質の期待をレビュー担当者と作成者の両方に伝達します。
• 相互責任感を高める–集団的なコード所有権と連帯 感を高める
• より良い解決策を見つける – 特定のコードを超えた新しいより良い解決策やアイデアを生み出します。
• QAガイドライン、ISO/IEC規格に準拠– 航空交通ソフトウェアや安全性が重要なソフトウェア など、一部の状況ではコードレビューが必須です。

コードレビューのこの定義は、静的コード分析、セルフチェック、テスト、ペアプログラミングなどの関連するソフトウェア品質保証技術と区別するものです。静的コード分析では、主なチェックは自動化されたプログラムによって実行され、セルフチェックでは作成者のみがコードをチェックし、テストではコードの実行が不可欠な部分であり、ペアプログラミングは実装中に継続的に実行され、個別のステップとして実行されません。^[1]

コード レビュー プロセスにはさまざまなバリエーションがあり、その一部については以下で詳しく説明します。追加のレビュー タイプは IEEE 1028 の一部です。

IEEE 1028-2008では、以下のレビューの種類が挙げられている。^[6]

• 経営レビュー
• 技術レビュー
• 検査
• ウォークスルー
• 監査

歴史的に、詳細に研究され説明された最初のコードレビュープロセスは、発明者であるマイケル・フェイガンによって「インスペクション」と呼ばれていました。^[7] このフェイガンインスペクションは、複数の参加者と複数のフェーズで慎重かつ詳細に実行される正式なプロセスです。正式なコードレビューは、ソフトウェア開発者が一連の会議に出席し、通常は印刷された資料を使用してコードを1行ずつレビューする従来のレビュー方法です。正式なインスペクションは非常に徹底的であり、レビュー対象のコードの欠陥を見つけるのに効果的であることが証明されています。^[7]

近年、^{[いつ? ]}多くの業界チームが、チケット、ユーザーストーリー、コミット、またはその他の作業単位で実行されたコードベースの変更に基づいて各レビューの範囲を決定する、より軽量なタイプのコードレビューを導入しています。^{[8] [3]さらに、各レビューを明示的に計画するのではなく、一般的には}プルリクエストの一部として、開発プロセスにレビュータスクを組み込むルールや慣習があります (例: 「すべてのチケットをレビューする必要があります」) 。このようなレビュープロセスは、「定期的な変更ベースのコードレビュー」と呼ばれます。^[1]この基本的なプロセスには多くのバリエーションがあります。 2017 年に 240 の開発チームを対象に行った調査では、チームの 90% が変更に基づくレビュープロセスを使用しており (レビューを使用する場合)、60% が定期的な変更ベースのコードレビューを使用していることがわかりました。^{[3]また、Microsoft、 [9]} Google、^[10] Facebookなどのほとんどの大規模ソフトウェア企業は、変更ベースのコードレビュープロセスに従っています。

Capers Jones が 12,000 件を超えるソフトウェア開発プロジェクトを継続的に分析した結果、形式検査の潜在的欠陥発見率は 60～65% の範囲にあることがわかりました。非形式検査の場合、この数字は 50% 未満です。ほとんどのテスト形式の潜在的欠陥発見率は約 30% です。^{[11] [12]} 「Best Kept Secrets of Peer Code Review」 という書籍に掲載されているコードレビューのケーススタディは、Capers Jones の研究と矛盾しており、^[11]軽量レビューは形式レビューと同じくらい多くのバグを発見できますが、より高速でコスト効率が高いことがわかりました。^[13]

研究によると、コードレビューのコメントの最大75%は機能性ではなくソフトウェアの進化性/保守性に影響を与えることが分かっており、^{[14] [15] [4] [16]}これは、コードレビューが製品やシステムのライフサイクルが長いソフトウェア企業にとって優れたツールであることを示唆しています。^[17] これはまた、コードレビューで議論される問題のうち15%未満がバグに関連するものであることを意味します。^[18]

コードレビューの有効性はレビュー速度に依存することが判明しました。コードレビュー速度は1時間あたり200〜400行のコードである必要があります。^{[19] [20] [21] [22]重要なソフトウェア（安全性が重要な}組み込みソフトウェアなど）の場合、1時間あたり数百行を超えるコードを検査およびレビューすると、エラーを見つけるには速すぎる可能性があります。^{[19] [23]}

静的コード解析ソフトウェアは、ソースコードに既知の脆弱性や欠陥の種類がないか体系的にチェックすることで、開発者が大量のコードをレビューする作業を軽減します。 ^[24] VDCリサーチによる2012年の調査では、調査対象の組み込みソフトウェアエンジニアの17.6%が現在、ピアコードレビューをサポートするために自動化ツールを使用しており、23.7%が2年以内にそれらを使用する予定であると報告されています。^[25]

• コミッター
• ソフトウェアレビュー
• ソフトウェアの品質
• コーディングのベストプラクティス
• ソフトウェア開発哲学のリスト

• コードレビューの 5 つのアンチパターン (Java Magazine、2020 年のベスト)