ソフトウェアエンジニア（プログラマー）がプログラムをレビューする

コードレビュー（ピアレビューとも呼ばれる）は、ソフトウェアの品質保証活動の一つであり、実装後または開発プロセス中に、1人または複数人がコンピュータプログラムのソースコードを検査する。作成者を除くチェック担当者は「レビュアー」と呼ばれる。少なくとも1人のレビュアーは、コードの作成者であってはならない。[1] [2]

コードレビューは、静的コード解析、セルフチェック、テスト、ペアプログラミングといった関連するソフトウェア品質保証手法とは異なります。静的解析は主に自動化ツールに依存し、セルフチェックはコード作成者のみが関与し、テストはコード実行を必要とし、ペアプログラミングは個別のステップではなく開発期間中継続的に実行されます。[1]

ゴール

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

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

レビューの種類

コードレビュープロセスにはいくつかのバリエーションがあり、IEEE 1028で追加の種類が規定されている。[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]

サポートツール

Static code analysis tools assist reviewers by automatically checking source code for known vulnerabilities and defect patterns, particularly for large chunks of code.[24] A 2012 study by VDC Research reports that 17.6% of the embedded software engineers surveyed currently use automated tools to support peer code review and 23.7% plan to use them within two years.[25]

See also

  • Five Code Review Antipatterns
  • Java Magazine, Best of 2020

References

  1. ^ a b c Baum, Tobias; Liskin, Olga; Niklas, Kai; Schneider, Kurt (2016). "A Faceted Classification Scheme for Change-Based Industrial Code Review Processes". 2016 IEEE International Conference on Software Quality, Reliability and Security (QRS). pp. 74–85. doi:10.1109/QRS.2016.19. ISBN 978-1-5090-4127-5. S2CID 9569007.
  2. ^ Kolawa, Adam; Huizinga, Dorota (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. p. 260. ISBN 978-0-470-04212-0.
  3. ^ a b c Baum, Tobias; Leßmann, Hendrik; Schneider, Kurt (2017). "The Choice of Code Review Process: A Survey on the State of the Practice". Product-Focused Software Process Improvement. Lecture Notes in Computer Science. Vol. 10611. pp. 111–127. doi:10.1007/978-3-319-69926-4_9. ISBN 978-3-319-69925-7.
  4. ^ a b Bacchelli, A; Bird, C (May 2013). "Expectations, outcomes, and challenges of modern code review" (PDF). Proceedings of the 35th IEEE/ACM International Conference On Software Engineering (ICSE 2013). Retrieved 2015-09-02.
  5. ^ Baum, Tobias; Liskin, Olga; Niklas, Kai; Schneider, Kurt (2016). "Factors Influencing Code Review Processes in Industry". Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering - FSE 2016. pp. 85–96. doi:10.1145/2950290.2950323. ISBN 9781450342186. S2CID 15467294.
  6. ^ IEEE Standard for Software Reviews and Audits. IEEE STD 1028-2008. August 2008. pp. 1–53. doi:10.1109/ieeestd.2008.4601584. ISBN 978-0-7381-5768-9.
  7. ^ a b Fagan, Michael (1976). "Design and code inspections to reduce errors in program development". IBM Systems Journal. 15 (3): 182–211. doi:10.1147/sj.153.0182.
  8. ^ リグビー, ピーター; バード, クリスチャン (2013). 「収束する現代ソフトウェアピアレビューの実践」. 2013年第9回ソフトウェア工学基礎合同会議議事録. pp.  202– 212. CiteSeerX 10.1.1.641.1046 . doi :10.1145/2491411.2491444. ISBN  9781450322379. S2CID  11163811。
  9. ^ MacLeod, Laura; Greiler, Michaela; Storey, Margaret-Anne ; Bird, Christian; Czerwonka, Jacek (2017). 「現場におけるコードレビュー：課題とベストプラクティス」（PDF） . IEEE Software . 35 (4): 34. doi :10.1109/MS.2017.265100500. S2CID  49651487. 2020年11月28日閲覧。
  10. ^ Sadowski, Caitlin; Söderberg, Emma; Church, Luke; Sipko, Michal; Baachelli, Alberto (2018). 「現代のコードレビュー：Googleのケーススタディ」.第40回国際ソフトウェア工学会議論文集：実践ソフトウェア工学. pp.  181– 190. doi : 10.1145/3183519.3183525 . ISBN 9781450356596. S2CID  49217999。
  11. ^ ab Jones, Capers (2008年6月). 「欠陥潜在性と欠陥除去効率の測定」(PDF) . Crosstalk, The Journal of Defense Software Engineering. オリジナル(PDF)から2012年8月6日にアーカイブ。 2010年10月5日閲覧。
  12. ^ Jones, Capers; Ebert, Christof (2009年4月). 「組み込みソフトウェア：事実、数字、そして未来」. Computer . 42 (4): 42– 52. Bibcode :2009Compr..42d..42E. doi :10.1109/MC.2009.118. S2CID  14008049.
  13. ^ Jason Cohen (2006).ピアコードレビューの秘密（現代的アプローチ、実践的アドバイス） . Smart Bear Inc. ISBN 978-1-59916-067-2。
  14. ^ Czerwonka, Jacek; Greiler, Michaela; Tilford, Jack (2015). 「コードレビューはバグを見つけない。現在のコードレビューのベストプラクティスが私たちの作業を遅らせる」2015 IEEE/ACM 第37回IEEE国際ソフトウェア工学会議(PDF) . 第2巻. pp.  27– 28. doi :10.1109/ICSE.2015.131. ISBN 978-1-4799-1934-5. S2CID  29074469 . 2020年11月28日閲覧.
  15. ^ Mantyla, MV; Lassenius, C. (2009). 「コードレビューで実際に発見される欠陥の種類とは？」(PDF) . IEEE Transactions on Software Engineering . 35 (3): 430– 448. Bibcode :2009ITSEn..35..430M. CiteSeerX 10.1.1.188.5757 . doi :10.1109/TSE.2008.71. S2CID  17570489. 2012年3月21日閲覧. 
  16. ^ Beller, M; Bacchelli, A; Zaidman, A; Juergens, E (2014年5月). 「オープンソースプロジェクトにおける現代のコードレビュー：どのような問題が解決されるのか？」(PDF) . 第11回ソフトウェアリポジトリマイニングに関するワーキングカンファレンス (MSR 2014) の議事録. 2015年9月2日閲覧.
  17. ^ Siy, Harvey; Votta, Lawrence (2004年12月1日). 「現代のコード検査には価値があるか？」(PDF) . unomaha.edu . 2015年4月28日時点のオリジナル(PDF)からアーカイブ。 2015年2月17日閲覧。
  18. ^ Bosu, Amiangshu; Greiler, Michaela; Bird, Chris (2015年5月). 「有用なコードレビューの特徴：Microsoftにおける実証的研究」(PDF) . 2015 IEEE/ACM 第12回ソフトウェアリポジトリマイニングワーキングカンファレンス. 2020年11月28日閲覧。
  19. ^ ab Kemerer, CF; Paulk, MC (2009-04-17). 「設計レビューとコードレビューがソフトウェア品質に与える影響：PSPデータに基づく実証的研究」. IEEE Transactions on Software Engineering . 35 (4): 534– 550. Bibcode :2009ITSEn..35..534K. doi :10.1109/TSE.2009.27. hdl : 11059/14085 . S2CID  14432409.
  20. ^ 「コードレビューメトリクス」Open Web Application Security Project . 2015年10月9日時点のオリジナルよりアーカイブ。 2015年10月9日閲覧。
  21. ^ 「ピアコードレビューのベストプラクティス」Smart Bear . Smart Bear Software. 2015年10月9日時点のオリジナルよりアーカイブ。2015年10月9日閲覧。
  22. ^ Bisant, David B. (1989年10月). 「プログラミングの生産性を向上させる2人による検査方法」 . IEEE Transactions on Software Engineering . 15 (10): 1294– 1304. doi :10.1109/TSE.1989.559782. S2CID  14921429. 2015年10月9日閲覧。
  23. ^ Ganssle, Jack (2010年2月). 「コード検査ガイド」(PDF) . Ganssle Group . 2010年10月5日閲覧。
  24. ^ Balachandran, Vipin (2013). 「自動静的解析とレビュー担当者の推薦を用いたピアコードレビューにおける人的労力の削減と品質向上」2013年第35回国際ソフトウェア工学会議 (ICSE) . pp.  931– 940. doi :10.1109/ICSE.2013.6606642. ISBN 978-1-4673-3076-3. S2CID  15823436。
  25. ^ VDC Research (2012-02-01). 「組み込みソフトウェア品質のための自動欠陥防止」. VDC Research . 2012年4月10日閲覧。