作業: コード レビュー
高品質なソフトウェアを構築している場合、実装のレビューは、コンパイル、統合、テストなどのほかの品質メカニズムを補足する作業です。実装をレビューする前に、コードをコンパイルし、コード規則チェッカーなどのツールを使用して、できるだけ多くのエラーを捕らえます。コードを視覚化できるツールの使用も検討します。ランタイム エラー検出ツールを使用してコードを実行すると、実装のレビューの前に、ほかのエラーも検出し、排除できる可能性があります。
実装をレビューする利点は次のとおりです。
- プロジェクトに共通のコーディング スタイルの導入と促進。コードのレビューは、メンバーがプログラミング ガイドラインに従うようにするために有効な方法です。これを確実にするためには、すべてのソース コード ファイルをレビューするよりも、作成者と実装担当者の結果をレビューするほうが重要です。
- 自動テストでは発見できないエラーの検出。実装のレビューによって、テストで検出されるエラーとは異なるエラーを捕らえることができます。
- 個人間での知識の共有や、経験のある個人から経験の浅い個人への知識の伝授。
実装をレビューするときに使用できる手法は数多くあります。次のいずれかを使用します。
- 検査: 実装を詳細に検査する正式な評価手法です。検査は最も生産性の高いレビュー手法と考えられていますが、これにはトレーニングと準備が必要です。
- ウォークスルー: 実装の作成者が 1 人以上のレビュー担当者と共に実装を検査する評価手法です。手法、スタイル、潜在的なエラー、コーディング標準違反などに関して、レビュー担当者が質問したり、コメントしたりします。
- コード読み: 1 ~ 2 人の作業者がコードを読みます。レビュー担当者の準備ができたら会合を行い、コメントと質問を発表します。会合は省略できますが、その場合は、代わりにレビュー担当者が作成者に対しコメントと質問を文書で渡します。コード読みは、小さな修正を確認するための「サニティ チェック」として推奨されます。
この役割のスキル要求は、役割: 実装担当者のスキル要求に似ています。この役割を演じる要員は、多くの場合、レビュー対象のコードで使用されているプログラミング言語の専門家です。多くのプロジェクトでは、この役割には実装チームの上級プログラマを配置します。
「 ガイドライン: レビュー」も参照してください。
目的 |
実装をレビューするためのチェックポイントを確立する。 |
この項では、実装のレビューで注意すべき点の例として、一般的なチェックポイントをいくつか紹介します。プログラミング ガイドラインが、コード品質についての主な情報源です。
基本
- コードがプログラミング ガイドラインに従っているか。
- コードはそれ自体で説明になっているか。コードを読んで理解できるか。
- コード規則チェック ツールかランタイム エラー検出ツール、またはその両方によって検出されたすべてのエラーが対処されているか。
コメント
- コメントは最新のものか。
- コメントは明瞭で正確か。
- コードが変更された場合、コメントを容易に修正できるか。
- コメントは方法ではなく、理由の説明に焦点を置いているか。
- すべての予想外の結果、例外的なケース、一時回避エラーがコメントされているか。
- 各演算の目的がコメントされているか。
- 各演算についてほかの関連事実がコメントされているか。
ソース コード
- 各演算には、その処理内容を説明する名前が付いているか。
- パラメータには記述的な名前が付いているか。
- 各演算の正常なパスは、その他の例外的なパスと明確に区別されているか。
- 長すぎる演算は、関連文をプライベートな演算に抽出することによって簡略化できないか。
- 長すぎる演算は、決定ポイント数を減らすことによって簡略化ができないか。決定ポイントとは、if、else、and、while、case 文のように、コードが異なるパスを取ることができる文です。
- ループのネストは最小化されているか。
- 変数には適切な名前が付いているか。
- コードは率直で、「巧妙な」解決法を避けているか。
目的 |
レビュー結果を文書化する。 識別された障害を確実に文書化する。
|
各レビュー会合の後、会合の結果をレビュー記録に文書化する必要があります。さらに、障害も変更依頼に文書化する必要があります (最終的には誰かに割り当てられ、解決されるよう手配されます)。
|