ピアレビューのまとめ¶

1. レビューの目的¶

• 欠陥の早期発見
• 手戻りの減少
• 教育

2. レビューの分類¶

1. インスペクション (最も公式)
2. チームレビュー
3. ウォークスルー
4. ペアプログラミング
5. ピアデスクチェック、パスアラウンド
6. アドホックレビュー (最も非公式)

3. レビューの原則¶

• 1. 始まる前に自身のエゴをチェックせよ
  • 作成者として心を広く持ち、改善の提案に受容的になる
  • レビュアとして作成者より頭がよいこと示すために行っているのではないことを心におく
• 2. レビューチームは小さくせよ
  • 通常参加者は3-7人
• 3. レビューでは問題の発見に努め、解決を試みるな
  • 識別された問題を解決するのはレビュー後
• 4. レビューミーティングは約2時間に制限せよ
  • 長時間のミーティングは成果が上がらない
  • 作業成果物はチームが1-2時間で調べられる論理的な量にすべき
• 5. 事前準備を要求する
  • 特に公式のレビュー
  • ミーティングの数日前には資料を受け取る
  • ミーティングの前にあらかじめ作業成果物を理解、問題を発見する

4. 準備¶

4.1 欠陥チェックリスト¶

• ソフトウェア作業成果物に見られる欠陥の典型例
  • あらかじめどのような点に気をつけて作成すればいいのかがわかる
  • コンパイラや静的解析ツールによって発見できる欠陥は記載しない

4.2 ルールセット¶

• チェックリストを補完、代替するもの
  • 命名規則
  • 書式等

4.3 計画¶

• 公式レビューの時間をあらかじめプロジェクトの計画に含める
• レビューの実施をマイルストーンとしないこと、レビューはタスクとして扱う
  • レビューに合格した時点でマイルストーンに達したと扱うこと
  • 早期に頻繁に公式および非公式のレビューを行うよう計画すること

5. レビュー開始¶

• コーディング規約に沿っていること
• コンパイルできること
• 単体テスト実行前
  • レビューの早期実施

6. レビューミーティング¶

6.1 リーディング¶

• 読み手が初期作業成果物をインスペクションチームに説明する
  • 読み手の言葉で説明する
  • ブロック単位で説明する
• 効果的な傾聴を促進するためのガイドライン
  • 気が散るものをミーティングルームから排除する
  • 精神的かつ感情的に気を散らさない。
  • リラックスする。
  • 言葉に気をつける。
  • 意味を明確にするために質問する。
  • 読み手が作業成果物のセクションのキーポイントを説明するまで判断は差し控える
  • 話題を変えたり、勝手に次の話題に移らない。現在議論されている話題に集中する。

6.2 問題指摘¶

• セクションごとに欠陥と課題を挙げる
• 様式に関する課題は、理解性や保守性に支障があるか基準違反の場合のみ指摘する。

6.3 課題記録¶

• 記録係が課題ログに各欠陥と課題を記録し、分類する。

7. レビュー終了¶

• 作成者は課題ログと誤字誤植一覧表のすべての課題に対処する必要がある
  • 修正しないと決めた箇所は必ず背景を記録し、バグ管理システムに登録すること
• 特定した根本原因ごとにいくつ欠陥が派生したか数える
  • パレートの法則
  • レビューで見つかった欠陥と種類を発生頻度で分類し、パターンを分析することにより、欠陥予防を行う