デザイン レビューとコード レビューを実施するためのガイドライン
更新 : 2007 年 11 月
以下のガイドラインでは、デザイン レビューとコード レビューに関するさまざまなテクニックを紹介しています。
必ず行うこと
レビューにはじっくり時間をかけて取り組むこと。
レビューの目的は、デザインとコードを十分に理解し、分析することにあります。レビューにかける最大時間は、コード作成に要した時間の半分、または当初デザインの計画にかかった時間の半分を目安としてください。
レビューは、レビュー担当者主導で行うこと。
レビューでは、レビュー担当者とその意見が最大限に尊重される必要があります。開発者自身がレビューの指揮をとった場合、他のレビュー担当者が問題を見落とす可能性があります。
レビュー ミーティングの前にコードまたはデザインに関するドキュメントに目を通す。
重要度のきわめて低いような変更をレビューする場合を除き、レビュー ミーティングの前に十分な準備作業が必要です。レビュー担当者が事前にコードまたはデザインに目を通さず、十分な準備作業を怠ると、レビュー ミーティングに参加したすべての人々の時間を無駄に費やすことになります。
グループ レビューの場合はチーム プロジェクト ポータルを使用する。
デザイン関連のドキュメントは、全員が簡単にアクセスしてレビューできるプロジェクト ポータルに公開します。公開したドキュメントの場所をレビュー担当者全員に知らせ、Internet Explorer のディスカッション機能を使って各自のコメントを追加するように依頼します。コードのレビュー方針を統一したい場合は、そのコードを Word 文書に貼り付けて、SharePoint サイトにも公開するようにします。詳細については、「チーム プロジェクト ポータルの使用」を参照してください。
チェックリストを使用する。
セキュリティ、エラー処理、スタイルなど、レビューの対象となる作業を区切って定義することによって作業効率を上げることができます。こうすることで、1 つの作業が完了した後、速やかに別の作業に移ることができます。チェックリストを使用することにより、レビューでカバーする必要のあるさまざまな作業を確実に実施できます。
コード レビューで見つかったすべての問題を追跡する。
見つかった問題は作業項目として記録しておくか、コード中にコメントとして、または、デザイン ドキュメントに問題として記録しておきます。そうしないと、問題が見失われ、コード レビューに費やした貴重な時間が無駄になってしまいます。詳細については、「方法 : 新しい作業項目を追加する」を参照してください。
避けるべきこと
コードまたはデザインをレビュー担当者に知らせずに変更する。
デザインまたはコードがレビュー工程に移った後で障害が見つかる場合もあります。しかし、レビュー ミーティングが開始されるまでは、決して問題を修正しないでください。ミーティングの前にコードまたはデザインを変更すると、レビュー担当者が混乱してしまいます。こうしたミスは、レビュー担当者の立場に立って扱うことが大切です。他のレビュー コメントと一緒に記録、追跡する必要があります。
お勧めすること
さまざまな分野から作業者を集める。
開発以外のさまざまな分野から作業者を集めることをお勧めします。彼らにデザインやコードに関するレビューを負担させることは現実問題として難しいかもしれませんが、見つかりにくい問題を発見する上で効果的です。各分野につき 1 名または 2 名の作業者がいれば十分です。それを超えると、レビューに時間がかかるだけでなく、管理も難しくなります。
すべてのコードとデザインをレビューする。
高品質の製品を目指すのであれば、すべてのコードとデザインをレビューの対象とすることが必要です。レビューには、コンパイラ チェックや単体テストを含め、また、最初の段階でデザインを文書化しておくことも大切です。