コード‐レビュー【code review】
コードレビュー
 |
コードレビュー（英: code review）は、ソフトウェア開発工程で見過ごされた誤りを検出・修正することを目的としてソースコードの体系的な検査（査読）を行う作業のこと。
概要
書き下ろされたばかりのソースコードや十分なテストがされていないコードは、潜在的にバグやセキュリティホール[注釈 1]などの不具合や問題が入り込んでいることが多い。また、直接的な不具合はなくとも、命名規則に従っていなかったり、モジュール分割のような構造設計が不適切だったりと、可読性やメンテナンス性に問題があることもある。最適化されていないコードは、メモリやプロセッサ時間といったリソース（計算資源）を無駄に消費して性能低下を招くような問題を抱えていることもある。ソフトウェア品質を高めるためにはこのような不具合や問題を除去していく必要がある。潜んでいる不具合や問題の数は一般的に、ソースコードを記述した開発者（プログラマ）の設計スキルや実装スキルにも左右されるが、これらを発見し修正するための方法のひとつが、本人または他者によりソースコードの査読を行うこと、すなわちコードレビューである[1]。
オンラインのソフトウェアリポジトリ（匿名のCVSなど）を使うと、複数の個人が共同でコードレビューを行うことができる。バージョン管理システム（VCS）およびホスティングサービスを利用したソフトウェア開発では、コード修正を含む分岐先ブランチのプルリクエスト（pull request）を提出する際にレビューを受けて、レビューを通過したコードのみが分岐元ブランチにマージされるようにすることで、修正により別の不具合が混入するリスクを低減させることができる。
コードレビューを自動化するソフトウェアを使うと、ソフトウェア開発者の代わりに典型的なセキュリティホールを見つける作業を行ってくれる。そのようなソフトウェアの例として、Flawfinder[2] や Rough Auditing Tool for Security (RATS)[3] などがある。GitHubと連携するSiderのような自動化サービスもある。
効果
コードレビューを実施することにより以下のような効果が期待できる。
- レビューで発見された同様または類似のバグについて、レビュー参加者内での共通認識を図ることができる。
- バグの隠蔽を減少させることが期待できる。
- レビューを行うことへの意識により、人に見せるコードを書くようになるため可読性が向上する。
- コーディング規約等に対する各自の認識のずれを修正することができる。
ただし、その性質から開発工程上の問題点も多く、批判もある（#批判の項目を参照）。
例
コードレビューがプロジェクトの質を向上させた例として、次のようなケースがある。[要出典]
- Blender - 3次元コンピュータグラフィックスデザイン用の統合ソフトウェアであり、オープンソース開発コミュニティが向上させた。
- Linuxカーネル - 当初リーナス・トーバルズの趣味的なプロジェクトだったが、現在では世界中の多数のプログラマがレビューや改良に関わっている。
批判
コードレビューよりもコーディングにあたっての規則や方法論を整備することのほうが重要であるとの見方もある。エクストリーム・プログラミング (XP) という技法では、ペアプログラミングというプラクティスを推奨しており、コーディングの最中に同時にコードレビューを行うようになっている。XP の信奉者は、リファクタリングやコードの前にテストを書くといったXPのプラクティスによってレビュー/書き直しが不要なコードを作成することでソフトウェア開発がスピードアップすると主張する。
DOD-STD-2167A[4] では、コードレビューは「労多く益少なし」としている。Lausen と Younessi（IEEE Software, July/Aug 1998, pg 69-73）では、行単位のコードレビューはほとんど価値がないと結論付けている。問題点を除去するという意味では、プログラマに行単位のコードレビューをさせることは、他の手法よりも生産性が低い。
コードレビューにより一定時間拘束されるため、担当作業の遅延が発生する可能性があるとの批判もある。
レビューの精度や粒度は属人的なスキルにも依存する。また、レビューの指摘項目や内容を組織内で共有できなければ、同じ指摘が相手を変えて何度も繰り返されるおそれがある。事前にレビューの目的や到達点を明確にして、開発メンバーの間で共有することも必要である[5]。
コンパイラからの警告や静的コード解析の結果は、潜在的な問題点を指摘していることも多い。警告のレベルを上げ、これらを無視せずにコードを正しく修正していけば、属人的で時間のかかるコードレビューに頼らずとも、問題点のいくつかは解消できることがある[6]。
脚注
注釈
- ^ 例えばメモリリーク、バッファオーバーラン（バッファオーバーフロー）、アクセス違反（セグメンテーション違反）、競合状態などの明らかに異常動作を引き起こすようなものや、書式文字列問題、ディレクトリトラバーサルなどのユーザー入力に依存した潜在的な問題を抱えているものもある。バッファオーバーフローや算術オーバーフローはセキュリティ脆弱性にもなりえる。
出典
- ^ IPA ISEC セキュア・プログラミング講座：C/C++言語編 第2章 脆弱性回避策とソフトウェア開発工程：ソースコードレビュー, Internet Archive
- ^ Flawfinder Home Page
- ^ Rough Auditing Tool for Security[リンク切れ]
- ^ DOD-STD-2167A[リンク切れ]
- ^ コードレビューを成功させるためにCTOが考えるべき7つのことー監修：高遠和也（株式会社LIG CTO） | FLEXY（フレキシー）
- ^ アプリケーション開発で質の高いコードレビューを実現するためのポイントとは ? ~ 後編~ - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
関連項目
外部リンク
 | 出典は列挙するだけでなく、脚注などを用いてどの記述の情報源であるかを明記してください。 |
「Code review」の例文・使い方・用例・文例
- code reviewのページへのリンク
