連載：Team Foundation Server 2008の下流工程への適用 第3回 実践的コード・レビュー アバナード株式会社　安藤 大祐（Microsoft MVP 2008 for Solutions Architect） 2009/05/12

Page1 Page2

　 前回の記事では、チーム開発におけるバージョン管理の活用方法を筆者が勧めるノウハウとともに紹介した。今回は、Team Foundation Server（以降TFS）を利用した実践的なコード・レビューについて説明したいと思う。

■コード・レビューとは

○コード・レビューの目的

　レビューする側・される側として、誰でも1度はコード・レビューにかかわったことがあると思うが、まずはコード・レビューの目的を整理しよう。

　コード・レビューの目的は大きく2つある。

（1）品質の最低保障
　 コード作成者自身の思い違いや単純ミスは、本人がいくら注意して気を付けて見直しても気付き分かりにくいものであり（頭の中で、「これは正しい！」と思い込んでしまっているため）、他人に見てもらい指摘を受けることで、初めて問題に気付き修正ができるケースは多い。

　また、品質に関するもう1つの効果として挙げられるのが、可読性の向上である。他人に読んでもらうことを常に意識すると、おのずと「読みやすいコーディング」「ルール（規約）どおりのコーディング」になりやすいという効果がある。後々、コードのメンテナンスにも役立つという点でも効果が期待できる。

（2）知識の共有／勉強
　 能力の高いプログラマーが書いたコードほど、勉強になるものはない（もちろん誰が1番優れたコードを書くかを競うわけではないが）。コードを短く書くためのノウハウや、可読性の高いコードを書くためのちょっとしたポイントを、他人のコードを読むことで得ることができ、開発者の教育という点でも非常にメリットがある。チームとしてプラスになっていくはずである。

○なぜコード・レビューは定着しづらいのか？

　上記のような目的やメリットがあるにもかかわらず、現実的にはコード・レビューはなかなか定着しないのが現場の実情だ。その理由として、以下の2点があると筆者は考える。

（A）作業時間の増加
　 コード・レビューは、レビュー依頼の作業やレビュー後のフィードバックを記述する作業など、双方が事務的な時間を要してしまうため、プロジェクトが忙しくなってくると手を抜きがちになる傾向がある。しかしフィードバックが正確に相手に伝わり、確実にアクションが行われていることを確認・追跡するためには、文書化することが必要不可欠である。また、フィードバックによる修正作業に時間を取られないためには、小まめにコード・レビューを行うことが好ましい。とはいえ、実作業時間とのトレードオフとなってしまうため、最終的に実作業時間が優先されることが多く、定着しにくいのではないか、と考える。

（B）レビューの形骸（けいがい）化
　2つ目の理由としては、レビューの目的や判断基準があいまいである、という点が挙げられる。あいまいであるがために、フィードバックの内容も誤字やネーミング・ルールのチェックといった価値の低いものばかりになりがちで、本来の必要性を感じられずに定着しないのではないか、と考える。

　（B）については、プロジェクトのコーディング標準を基に、明確な判断基準（レビュー・クライテリア）を作成することが重要である。また、Visual Studio Team System（以降、VSTS）の静的コード分析機能も極めて有効で、単純なコーディング・ルールの検証はすべてツールで自動化できるため、レビュワーのチェック作業の負荷を減らすことができ、より深い内容のコード・レビューが可能となる。

　（A）については、以下で説明する、「Team Review」と呼ばれるTFSのアドオンを利用して作業を省力化できる。

【コラム】コード・レビューとペア・プログラミング

（1）品質の最低保障や（2）知識の共有／勉強を実現するための手段としては、コード・レビューのほかに、ペア・プログラミングがある。ペア・プログラミングでは、2人のプログラマーが1台の端末を使い、共同でソフトウェアを開発する手法である。2人1組で作業をすることで、常にフィードバックを受けることができ、品質の向上と情報の共有が可能である。 　コード・レビューとペア・プログラミングのどちらを採用して開発を進めるかはケース・バイ・ケースであるが、筆者はコード・レビューの方が無難でないかと考えている。その理由としては、まず制約の問題がある。ペア・プログラミングは2人1組で作業を進めるため、物理的に場所が離れている場合には採用できない。次に費用対効果の問題がある。1つの作業をするにあたって、ペアで作業するということは単純にその作業を半分の時間で終わらせないといけない。極めて難易度が高いタスクであれば実現は可能だが、プロジェクトには1人でもペアでも生産性に変わりのないタスクも多数存在する。従って、コード・レビューによるチェックを基本方針とし、極めて複雑な機能や、失敗のリスクが高い機能にのみポイントを絞ってペア・プログラミングをしていくことが望ましいのではないか、と考える。

■Team Reviewの概要とセットアップ

　Team Reviewとは、CodePlexで公開されているTFSおよびVSTS用のアドオンであり、コード・レビューのワークフローをVSTSに統合することが可能となる。

＜提供される機能＞

• コード・レビューの結果を記述するためのカスタムの作業項目（Code Review Response）
• Code Review Responseの記述を自動化するVisual Studio用のアドオン

　Team Reviewは下記のURLからダウンロードできる。執筆時点（2009年4月）での最新バージョンは「1.0.9」で、VS 2005／2008／2010版の3種類が存在する。以降では、VS 2008版で利用方法を説明する。

• Team Reviewのダウンロード

○Team Reviewのセットアップ方法

　Team Reviewのセットアップは、TFSのサーバに対して実施する「プロセス・テンプレートのカスタマイズ」と、各クライアントの開発環境で実施する「Visual Studioアドオンのインストール」の2ステップが必要だ。

プロセス・テンプレートのカスタマイズ

　Team Reviewのダウンロード・ファイルに含まれる「Code Review Response.xml」ファイルを、利用対象のチーム・プロジェクトに対してインポートする。インポート方法は、TFS付属の「witimport.exe」を利用する方法（下記）と、VS 2008 SP1に含まれるプロセス・テンプレート・エディタを利用する方法の2種類があり、好きな方を利用すればよい。

witimport /f <Code Review Response.xmlファイルのパス> /t <TFSサーバ名> /p <チーム・プロジェクト名>

witimport.exeを使ってCode Review Responseをインポートする場合のコマンド例

Visual Studioコマンド・プロンプトから上記のコマンドを実行する。

【注意】日本語環境のTFSでTeam Reviewを利用する場合の注意点

実はこのTeam Review、そのままでは日本語環境のTFSでは利用できない。というのも、「Code Review Response.xml」に含まれているフィールド名が、英語と日本語とで一致せず、インポートする際にエラー（エラーコード：TF26177）が表示されてしまうからだ。 　そのため、日本語環境でセットアップするためには、テキスト・エディタやプロセス・テンプレート・エディタを利用して、Code Review Response.xml内の該当のフィールド名を英語から日本語へ修正する必要がある。 　修正が必要な項目の一部を以下に示す（修正が必要なフィード名は、エラー・メッセージとして表示されるため、エラー・メッセージが消えるまで修正を続ければよい）。 System.Title："Title" → "タイトル" System.State："State" → "状態" System.Rev　："Rev" → "バージョン" （修正が必要な項目は50近くある）

Visual Studioアドオンのインストール

　Visual Studioアドオンのインストールは極めて簡単である。ダウンロード・ファイルに含まれる「setup.exe」を実行すると、インストール・ウィザードが起動される。一本道のため、そのまま［Next >］を押していけばよい。

図1 Team Reviewのアドオン部分のインストール・ウィザード

　上記の2つのステップで、Team Reviewを利用する環境は整った。以下では、Team Reviewを活用したコード・レビューのワークフローについて説明する。

INDEX
	[連載] Team Foundation Server 2008の下流工程への適用
	第3回 実践的コード・レビュー
	1．コード・レビューとは？／Team Reviewの概要とセットアップ
	2．Team Reviewを活用したコード・レビューのワークフロー

「Team Foundation Server 2008の下流工程への適用」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）