コードレビュー

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

コードレビュー(ピアレビューとも呼ばれる)は、ソフトウェアの品質保証活動の一種であり、実装後または開発プロセス中に、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 ]

サポートツール

静的コード解析ツールは、特に大規模なコードチャンクにおいて、ソースコード内の既知の脆弱性や欠陥パターンを自動的にチェックすることで、レビュー担当者を支援します。[ 24 ] VDCリサーチによる2012年の調査では、調査対象となった組み込みソフトウェアエンジニアの17.6%が現在、ピアコードレビューをサポートするために自動化ツールを使用しており、23.7%が2年以内に使用することを計画していると報告されています。[ 25 ]

参照

参考文献

  1. ^ a b c Baum, Tobias; Liskin, Olga; Niklas, Kai; Schneider, Kurt (2016). 「変更ベースの産業用コードレビュープロセスのためのファセット分類スキーム」. 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).自動欠陥予防:ソフトウェア管理におけるベストプラクティス. 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). 「コードレビュープロセスの選択:実践の現状に関する調査」.プロダクト重視のソフトウェアプロセス改善. コンピュータサイエンス講義ノート. 第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 (2013年5月). 「現代のコードレビューへの期待、成果、そして課題」(PDF) . 第35回IEEE/ACM国際ソフトウェア工学会議 (ICSE 2013) の議事録. 2015年9月2日閲覧
  5. ^ Baum, Tobias; Liskin, Olga; Niklas, Kai; Schneider, Kurt (2016). 「業界におけるコードレビュープロセスに影響を与える要因」. 2016年第24回ACM SIGSOFT国際ソフトウェアエンジニアリング基礎シンポジウム - FSE 2016 議事録. pp.  85– 96. doi : 10.1145/2950290.2950323 . ISBN 9781450342186. S2CID  15467294 .
  6. ^ IEEEソフトウェアレビューおよび監査標準. IEEE STD 1028-2008. 2008年8月. pp.  1– 53. doi : 10.1109/ieeestd.2008.4601584 . ISBN 978-0-7381-5768-9
  7. ^ a b Fagan, Michael (1976). 「プログラム開発におけるエラーを削減するための設計とコード検査」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. ^ a b 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. ^ a b 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 Project2015年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日閲覧。