ソースコードレビュー理由をまとめてみた
こんにちは。次世代システム研究室のT.D.Qです。
ウェブアプリケーションの開発を担当しています。
品質の高いウェブアプリケーションを開発するためには、早期のチェックによってミスを発見し、欠陥を回避することが不可欠である。そのためソースレビューの重要性はたいへん高いものの、ソースレビューの種類をきちんと理解し実践している人は意外に少ないようです。
今回、コードレビューをする理由とレビュー手段、レビューによって、残した結果は何だったのか、レビューの観点を社内の各プロジェクトでの事例をヒアリングし、まとめてみました。
以下の画像は、マインドマップ形でヒアリングした情報をまとめた結果です。
何のためにソースレビューを実施するのか
今回、社内の各PRJの担当者にヒアリングしたとき、「“ソースレビュー”やっています」が全員の回答で、自社開発でソースレビューが大事にしているが分かりました。レビューの理由は以下の通りで挙げられます。1.品質保障
・機能仕様がロジック上正しく実装されているかを確認するため
・不具合発見のため
・コード標準化・統一化のため
・コードの質（仕様の認識違いは無いか、バグを生む可能性ないか、メンテしやすいかなど）の点で全体的なクオリティを向上させるため
2.開発者の教育
・実装者の開発力向上のため
・システム仕様の把握
・コードリーディングの技術
・コミュニケーション向上
・コーディング ベストプラクティス
ソースレビューとは、人間によるコーディング作業を行った段階で、そのソースプログラムを目視により見直す作業です。 ソースプログラムのミスをテストで発見する前に、人間のチェックによって障害を発見するというのが直接の目的です。そのほかにも、他人の目でソースプログラムを見直すことで様々なコーディングの間違いや勘違いを発見するなど、重要な効果が期待できます。
また、品質特性（信頼性、保守性、使用性、効率性、機能性、移植性）の高いコードを書くためのノウハウや、可読性の高いコードを書くためのポイントを、他人のコードを読むことで勉強することができ、開発者の教育という点でもメリットがあります。
ソースレビューによる品質保証の観点
品質保証レビューは，プロジェクト品質を客観的に審査し，プロジェクトの健全な運用を阻害する要因を早期に検出することが目的です。プロジェクト品質の客観的評価に基づく改善勧告を重視しています。品質保証の観点でソースレビューを実施するとき、以下の目的が挙げられます。1.早期欠陥除去のため
レビューの目的の1つは不具合や矛盾の早期発見です。開発の後工程でバグが発見されるほど修正にかかるコストは大きくなります。開発の早い段階で不具合を見つけることがコスト削減につながります。以下の例は、米国のSmartBear Software社の検証データですが、レビューするときは、レビューしないより、リリース後、発生した不具合の数がかなり減ったことと不具合修正コストが半分以上減ったことが分かりました。
 |
 |
| 図1．ソースレビューで早期欠陥除去の効果（米国のSmartBear Software社） | |
2.コード標準化・統一化のため
ソースレビューで、この観点に関する指摘事項が約70%占めていることは、Mika V. MäntyläさんとCasper Lasseniusさんの研究で2009年に発表されました。
 |
| 図2．ソースレビューでコード標準化に関する指摘事項が70%占める(http://www.hitachi-solutions.co.jp/forum/tokyo/vol57/pdf/pb_seminar57_1.pdf) |
ソフトウェア品質の特性と言っても様々な観点があります。以下に主なソフトウェア品質要因を列挙します。ソースレビューで品質要因をチェックし、コンパイラでは検出できないソースコードの問題箇所を検出することで、ソフトウェアの品質を強化することが期待できます。
 |
| 図3．ソースレビューによる品質の特性を維持する観点(http://homepage3.nifty.com/kaku-chan/q_and_p/what_quality.html) |
ソースレビューによる教育の観点
ソースレビューでノウハウの共有によって、プロジェクトに関連する技術的トピックスについて他の開発者の知識レベルを引き上げる。各プロジェクトをヒアリング結果で以下のポイントが挙げられます・システム仕様の把握
・品質の特性についての理解
・欠陥の理解とバグの認識
・コードリーディングの能力向上
・コミュニケーション向上
ソースレビューは開発ノウハウを交換するのに非常に有効です。レビューする時、フィードバックを交換すると、コードの品質が改善されるだけでなく、ノウハウの共有も行えて一挙両得です。
そうしてチーム内の共通認識を育て、チームの底力を上げていく。また、開発者、特にプログラマーはソースコードを読む能力が上がれば、プログラミング技術上達に直結すると思っています。
気をつけてコードを書いてテストを行っていても、うっかりミスで初歩的なバグを入れてしまうことはなかなか避けられません。他人の目を通すと、そうしたミスをキャッチできます。なので、ソースレビュー依頼するとき、アサインされている人は一般的には同じプロジェクト内の実装担当者以外の開発者ですが、可能であれば、他のプロジェクトメンバーにもpull request(merge request)を共有して議論に参加したほうがいいかもしれません。ソースレビューはコミュニケーションなので、普段接してない人をアサインしてみるのも面白いかと思います。
ソースレビューの流れ
インターネット業界で、ソースコードの管理にGithub/Gitlabを利用している会社は増えています。次世代システム研究室でも、Gitlabがよく使用されているため、今回、Gitlabの特徴的なスタイルであるソースレビューフロー（図3）を例に、Gitlabによるソースレビューフローを纏めました。具体的なソースレビューの事例は、次回のブログを紹介したいと思います。
 |
| 図4．Gitlabによるソースレビューフロー |
開発者は実装したソースコードをGitlabへPushします。Gitlab上でマージリクエスト作成する同時に、レビューアーをアサインします。Gitlabのアカウント作成をしておけば、メールでソースレビュー依頼を通知します。
Step 2.ソースレビュー依頼確認
レビューアーは、Gitlabにアクセスし、ソースレビューを確認します。
Step 3.レビュー結果登録
レビューアーは、ソースコードをレビューし、結果（コメント）をGitlabに登録します。レビュー結果をレビュー依頼者（開発者）にメールで通知します。
Step 4.レビュー結果確認 レビュー依頼者はレビュー結果をGitlabで確認し、
レビューアーが指摘された項目ごとを回答します。ソース修正する必要の場合、修正して再度GitlabへPushします。
Step 5.レビュー終了
レビューでOKの場合、レビューアーがマージリクエストを承認し、ソースレビューを閉じます。
まとめ
今回はソースレビューの観点を纏めました。ソースレビューは品質を高める効果的な方法のひとつで、開発者の教育のため実施する価値がありますね。ソースレビューにはある程度の時間がかかりますが、効果的に行えば、要する時間よりも、得られるメリットの方が大きいはずです。次回、次世代システム研究室で実施しているソースレビューの事例について紹介したいと思います。参考資料
・SmartBear Software .Inc. “Best kept secrets of peer code review”・Mika V. Mäntylä and Casper Lassenius. 2009. “What types of defects are really discovered in code reviews”.
・ソースコードの品質向上のための効果的で効率的なコードレビュー
・品質とは何か
・ソフトウェア品質マネジメント能力を高めれば組織は強くなれる
