Peace Pipe: 効率の良いコードレビュー [software] を読んでソースコードレビューの必要性について考えてみたい。
ソースコードのレビューをやっているか?
ツールなどを使ったソースコードチェックは多くのSIerで行われていると思うが、ここではソースコードレビューについて。 プロジェクトによっては「全くやっていない」「重要なプログラムだけ選んでやっている」など、プロジェクトの状況、状態によって異なると思う。
自分の過去の開発経験では、プリントアウトしたソースコードを2人で組になって読み合わせをした。
- 1. 開発者がレビュアにロジックを説明する。
- 2. レビュアーは疑問に思ったことを聞く。
- 3. ここで、機能的な不具合、アルゴリズム、モジュール分割をみる
時間的な制限があるためすべてのコードについて実施できない場合がほとんどだったため、レビュー対象となるソースコードは次のような点を考慮してレビュー対象を決めていた気がする。
- 特定の担当者が作成したコード
- 共通モジュール
- サーバサイドのコード
- ソースコード(処理)が複雑であるコード(プロジェクトによって複雑度は異なる）
- ソースコードをざっと眺め、引っかかるコード、気になったコードを見つけた場合
ソースコードレビューについて、誰が行うか、観点は?の説明されている以下のサイトが参考になる。
IPA ISEC 第2章 脆弱性回避策とソフトウェア開発工程：ソースコードレビュー
観点
- コーディング規約、命名規約に従っているか
- 言語特有の技術的なノウハウに違反していないか
- ロジックエラー、仕様違反していないか
- 深すぎるネスト、巨大すぎる関数など･･･
ソースコードレビューの必要性として特に言われることとして、以下の2点がある。
「開発者のスキルが上がる」
開発者よりも高いスキルをもつレビュアが、ソースコードのレビューを行うことで、書き方の指導や考え方のトレースをすることになり、開発者のスキルを向上させることができる。 ソフトウェア開発では特にその”人”のスキルに依存しがちである。長い目で見て開発者のスキルを上げることが品質の良いシステムを開発する上で最も効果がある。
「ソースコードの質がよくなる」
ソースコードレビューによりバグを抽出することで品質が向上する。検出されなければいけない工程で確実に検出できることは必須であると思う。当然、前工程で検出されたバグ修正も少ないコストで可能である。 ソースコードが第三者の目に触れず、開発者だけが「正しい」と認識することは避けるべきであり、その仕組みをチーム内に作っておくことは重要である。 進捗ミーティングや報告会と同様にコードレビューを定着させるべきだと思う。