目的
  • 実装を検証する。
ステップ
入力とする成果物:    結果となる成果物:   
頻度: 反復ごと 
役割:  テクニカル レビュー担当者 
ツール メンター:   

ワークフローの詳細:   

一般的な推奨事項 ページの先頭へ

目的 各レビューの一般的な推奨事項を提供する。

高品質なソフトウェアを構築している場合、実装のレビューは、コンパイル、統合、テストなどのほかの品質メカニズムを補足する作業です。実装をレビューする前に、コードをコンパイルし、コード規則チェッカーなどのツールを使用して、できるだけ多くのエラーを捕らえます。コードを視覚化できるツールの使用も検討します。ランタイム エラー検出ツールを使用してコードを実行すると、実装のレビューの前に、ほかのエラーも検出し、排除できる可能性があります。

実装をレビューする利点は次のとおりです。

  • プロジェクトに共通のコーディング スタイルの導入と促進。コードのレビューは、メンバーがプログラミング ガイドラインに従うようにするために有効な方法です。これを確実にするためには、すべてのソース コード ファイルをレビューするよりも、作成者と実装担当者の結果をレビューするほうが重要です。
  • 自動テストでは発見できないエラーの検出。実装のレビューによって、テストで検出されるエラーとは異なるエラーを捕らえることができます。
  • 個人間での知識の共有や、経験のある個人から経験の浅い個人への知識の伝授。

実装をレビューするときに使用できる手法は数多くあります。次のいずれかを使用します。

  • 検査: 実装を詳細に検査する正式な評価手法です。検査は最も生産性の高いレビュー手法と考えられていますが、これにはトレーニングと準備が必要です。
  • ウォークスルー: 実装の作成者が 1 人以上のレビュー担当者と共に実装を検査する評価手法です。手法、スタイル、潜在的なエラー、コーディング標準違反などに関して、レビュー担当者が質問したり、コメントしたりします。
  • コード読み: 1 ~ 2 人の作業者がコードを読みます。レビュー担当者の準備ができたら会合を行い、コメントと質問を発表します。会合は省略できますが、その場合は、代わりにレビュー担当者が作成者に対しコメントと質問を文書で渡します。コード読みは、小さな修正を確認するための「サニティ チェック」として推奨されます。

この役割のスキル要求は、役割: 実装担当者のスキル要求に似ています。この役割を演じる要員は、多くの場合、レビュー対象のコードで使用されているプログラミング言語の専門家です。多くのプロジェクトでは、この役割には実装チームの上級プログラマを配置します。

../workguid/wg_rview.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんガイドライン: レビュー」も参照してください。

実装のチェックポイントの確立 ページの先頭へ

目的 実装をレビューするためのチェックポイントを確立する。 


この項では、実装のレビューで注意すべき点の例として、一般的なチェックポイントをいくつか紹介します。プログラミング ガイドラインが、コード品質についての主な情報源です。

基本

  • コードがプログラミング ガイドラインに従っているか。
  • コードはそれ自体で説明になっているか。コードを読んで理解できるか。
  • コード規則チェック ツールかランタイム エラー検出ツール、またはその両方によって検出されたすべてのエラーが対処されているか。

コメント

  • コメントは最新のものか。
  • コメントは明瞭で正確か。
  • コードが変更された場合、コメントを容易に修正できるか。
  • コメントは方法ではなく、理由の説明に焦点を置いているか。
  • すべての予想外の結果、例外的なケース、一時回避エラーがコメントされているか。
  • 各演算の目的がコメントされているか。
  • 各演算についてほかの関連事実がコメントされているか。

ソース コード

  • 各演算には、その処理内容を説明する名前が付いているか。
  • パラメータには記述的な名前が付いているか。
  • 各演算の正常なパスは、その他の例外的なパスと明確に区別されているか。
  • 長すぎる演算は、関連文をプライベートな演算に抽出することによって簡略化できないか。
  • 長すぎる演算は、決定ポイント数を減らすことによって簡略化ができないか。決定ポイントとは、ifelseandwhilecase 文のように、コードが異なるパスを取ることができる文です。
  • ループのネストは最小化されているか。
  • 変数には適切な名前が付いているか。
  • コードは率直で、「巧妙な」解決法を避けているか。

レビュー記録の準備と障害の文書化 ページの先頭へ

目的 レビュー結果を文書化する。
識別された障害を確実に文書化する。 


各レビュー会合の後、会合の結果をレビュー記録に文書化する必要があります。さらに、障害も変更依頼に文書化する必要があります (最終的には誰かに割り当てられ、解決されるよう手配されます)。



Rational Unified Process   2003.06.15