コードレビュー

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

多くの場合、品質上の問題を直接発見することが主な目的ですが、[3]コード レビューは通常、次の目的の組み合わせを達成するために実行されます。[4] [5]

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

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

レビューの種類

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

IEEE 1028-2008 には次のレビュー タイプがリストされています: [6]

  • マネジメントレビュー
  • 技術レビュー
  • 検査
  • ウォークスルー
  • 監査

検査(正式)

歴史的に、詳細に研究され説明された最初のコードレビュープロセスは、その発明者であるMichael Faganによって「インスペクション」と呼ばれていました。[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 Research による 2012 年の調査では、調査対象となった組み込みソフトウェア エンジニアの 17.6% がピア コード レビューをサポートするために現在自動ツールを使用しており、23.7% が 2 年以内に自動ツールを使用すると予想していると報告しています。[25]

こちらも参照

外部リンク

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

参考文献

  1. ^ abc ボーム、トビアス; リスキン、オルガ。ニクラス、カイ。シュナイダー、カート (2016)。「変更ベースの工業規格レビュープロセスのためのファセット分類スキーム」。ソフトウェアの品質、信頼性、セキュリティに関する 2016 IEEE 国際会議 (QRS)74–85ページ。土井:10.1109/QRS.2016.19。ISBN 978-1-5090-4127-5S2CID  9569007。
  2. ^ コラワ、アダム; ホイジンガ、ドロタ (2007)。自動欠陥防止: ソフトウェア管理のベスト プラクティス。Wiley-IEEE Computer Society Press。p. 260.ISBN _ 978-0-470-04212-0
  3. ^ abc ボーム、トビアス; レスマン、ヘンドリック。シュナイダー、カート (2017)。「コードレビュープロセスの選択: 実践の現状に関する調査」。製品中心のソフトウェアプロセスの改善コンピューターサイエンスの講義ノート。Vol. 10611。111–127 ページ。土井:10.1007/978-3-319-69926-4_9。ISBN 978-3-319-69925-7
  4. ^ ab バッチェリ、A; バード、C (2013 年 5 月)。「最新のコードレビューの期待、成果、課題」(PDF)第 35 回 IEEE/ACM ソフトウェア エンジニアリング国際会議 (ICSE 2013) の議事録2015 年 9 月 2 日に取得
  5. ^ ボーム、トビアス; リスキン、オルガ。ニクラス、カイ。シュナイダー、カート (2016)。「業界のコードレビュープロセスに影響を与える要因」。2016 年のソフトウェア エンジニアリングの基礎に関する第 24 回 ACM SIGSOFT 国際シンポジウムの議事録 - FSE 201685–96ページ。土井:10.1145/2950290.2950323。ISBN 9781450342186S2CID  15467294。
  6. ^ ソフトウェアのレビューと監査に関する IEEE 規格。IEEE STD 1028-2008。2008 年 8 月。1 ~ 53 ページ。土井:10.1109/ieeestd.2008.4601584。ISBN 978-0-7381-5768-9
  7. ^ ab フェイガン、マイケル (1976). 「プログラム開発におけるエラーを減らすための設計とコードの検査」。IBM システム ジャーナル15 (3): 182–211。土井:10.1147/sj.153.0182。
  8. ^ リグビー、ピーター; バード、クリスチャン(2013)。「コンバージェントな現代ソフトウェアピアレビューの実践」。2013 年第 9 回ソフトウェアエンジニアリングの基礎に関する合同会議の議事録202~212ページ。CiteSeerX 10.1.1.641.1046土井:10.1145/2491411.2491444。ISBN  9781450322379S2CID  11163811。
  9. ^ ローラ・マクラウド; グライラー、ミカエラ。ストーリー、マーガレットアン。バード、クリスチャン。チェルウォンカ、ヤチェク(2017)。「最前線のコードレビュー: 課題とベストプラクティス」(PDF)IEEE ソフトウェア35 (4): 34.土井:10.1109/MS.2017.265100500。S2CID  49651487 2020年11月28日に取得
  10. ^ サドウスキー、ケイトリン; セーダーバーグ、エマ。チャーチ、ルーク。シプコ、ミハル。アルベルト・バーチェッリ (2018)。「最新のコードレビュー: Google でのケーススタディ」。第 40 回ソフトウェア エンジニアリング国際会議の議事録: ソフトウェア エンジニアリングの実践181–190ページ。土井: 10.1145/3183519.3183525ISBN 9781450356596S2CID  49217999。
  11. ^ ab ジョーンズ、ケイパーズ (2008 年 6 月)。「欠陥の可能性と欠陥除去効率の測定」(PDF)Crosstalk、防衛ソフトウェア工学ジャーナル。2012 年 8 月 6 日のオリジナル(PDF)からアーカイブされました2010 年 10 月 5 日に取得
  12. ^ ジョーンズ、ケイパーズ; エバート、クリストフ (2009 年 4 月)。「組み込みソフトウェア: 事実、数字、そして未来」。コンピューター42 (4): 42-52。土井:10.1109/MC.2009.118。S2CID  14008049。
  13. ^ ジェイソン・コーエン (2006)。ピアコードレビューの極秘事項 (最新のアプローチ、実践的なアドバイス)株式会社スマートベアISBN 978-1-59916-067-2
  14. ^ チェルウォンカ、ヤチェク; グライラー、ミカエラ。ティルフォード、ジャック(2015)。「コード レビューではバグは見つかりません。現在のコード レビューのベスト プラクティスがどのように速度を低下させているか」。2015 IEEE/ACM 第 37 回 IEEE ソフトウェア エンジニアリング国際会議(PDF)Vol. 2. 27 ~ 28 ページ。土井:10.1109/ICSE.2015.131。ISBN 978-1-4799-1934-5S2CID  29074469 2020年11月28日に取得
  15. ^ マンティラ、MV; ラッセニウス、C. (2009)。「コードレビューで実際に発見される欠陥は何ですか?」(PDF)ソフトウェアエンジニアリングに関するIEEEトランザクション35 (3): 430–448。CiteSeerX 10.1.1.188.5757土井:10.1109/TSE.2008.71。S2CID  17570489 2012 年 3 月 21 日に取得 
  16. ^ ベラー、M; バッチェリ、A; ザイドマン、A; ユルゲンス、E (2014 年 5 月)。「オープンソース プロジェクトにおける最新のコード レビュー: どの問題が修正されますか?」(PDF)第 11 回マイニング ソフトウェア リポジトリに関するワーキング カンファレンスの議事録 (MSR 2014) 2015 年 9 月 2 日に取得
  17. ^ シー、ハーベイ; ヴォッタ、ローレンス (2004-12-01)。「モダンコードインスペクションには価値があるのか​​?」(PDF)うのまは.edu2015 年 4 月 28 日にオリジナル(PDF)からアーカイブされました2015 年 2 月 17 日に取得
  18. ^ ボス、アミアンシュ; グライラー、ミカエラ。バード、クリス (2015 年 5 月)。「有用なコード レビューの特徴: Microsoft での実証研究」(PDF)2015 IEEE/ACM 第 12 回マイニング ソフトウェア リポジトリに関する作業会議2020年11月28日に取得
  19. ^ ab ケメラー、CF; ポールク、MC (2009-04-17)。「ソフトウェア品質に対する設計とコードレビューの影響: PSP データに基づく実証研究」。ソフトウェアエンジニアリングに関するIEEEトランザクション35 (4): 534–550。土井:10.1109/TSE.2009.27。hdl : 11059/14085S2CID  14432409。
  20. ^ 「コードレビューメトリクス」. Web アプリケーション セキュリティ プロジェクトを開きます2015-10-09 のオリジナルからアーカイブ2015 年10 月 9 日に取得
  21. ^ 「ピアコードレビューのベストプラクティス」. スマートベアスマートベア ソフトウェア。2015-10-09 のオリジナルからアーカイブ2015 年10 月 9 日に取得
  22. ^ ビサント、デヴィッド B. (1989 年 10 月)。「プログラミングの生産性を高める二人点検法」。ソフトウェアエンジニアリングに関するIEEEトランザクション15 (10): 1294–1304。土井:10.1109/TSE.1989.559782。S2CID  14921429 2015 年10 月 9 日に取得
  23. ^ ジャック、ガンスル (2010 年 2 月) 「コード・インスペクションのガイド」(PDF)ガンスルグループ2010 年 10 月 5 日に取得
  24. ^ バラチャンドラン、ヴィピン (2013). 「自動静的分析とレビュー担当者による推奨を使用して、ピアコードレビューにおける人的労力を削減し、品質を向上させます。」2013 第 35 回ソフトウェア エンジニアリング国際会議 (ICSE)931–940ページ。土井:10.1109/ICSE.2013.6606642。ISBN 978-1-4673-3076-3S2CID  15823436。
  25. ^ VDC リサーチ (2012-02-01)。「組み込みソフトウェア品質のための自動欠陥防止」。VDCリサーチ2012 年 4 月 10 日に取得
Retrieved from "https://en.wikipedia.org/w/index.php?title=Code_review&oldid=1190843329"