Skip to content

5.2 レビューにおけるチェックリストの活用

レビューにおけるチェックリストの役割

Section titled “レビューにおけるチェックリストの役割”

テクニカルレビューにおいて「チェックリスト」を使用することは、参加者が見落としがちな特定のポイントを確実に確認させるための非常に有効な手段です。

また、チェックリストは「これはすべてのレビューで使用している共通のリストであり、あなたの成果物だけを特別に批判しているわけではない」というメッセージを伝え、レビューを個人的な指摘ではなく「客観的な評価」にする効果もあります。

チェックリストの構築とカスタマイズ

Section titled “チェックリストの構築とカスタマイズ”

チェックリストは、汎用的なものだけでなく、セキュリティや性能効率性など、特定の品質特性に焦点を当てたものを作成することもできます。最も有用なチェックリストは、以下のような要素を反映させるため、各組織で徐々に作成・進化させていく必要があります。

  • プロダクトの性質やローカルの開発環境
  • スタッフのスキルや使用ツール
  • 優先度や、過去の成功例・欠陥の履歴
  • プロジェクト特有の問題(性能やセキュリティなど)

1. アーキテクチャレビュー (Architecture Reviews)

Section titled “1. アーキテクチャレビュー (Architecture Reviews)”

ソフトウェアアーキテクチャとは、システムの基本的な概念や特性であり、その要素、関係性、及び設計・進化の原則が組み込まれたものです。アーキテクチャレビューでは、これらが要件を満たしているかを検証します。

「時間効率性」のアーキテクチャチェックリスト例

Section titled “「時間効率性」のアーキテクチャチェックリスト例”

例えば、Webサイトの性能(時間効率性)を評価する場合、以下のようなアーキテクチャ上の工夫が適切に実装されているかをチェックします。

  • コネクションプーリング: データベース接続の共有プールを確立し、実行時のオーバーヘッドを削減しているか。
  • ロードバランシングと分散処理: 複数のリソース間で負荷を均等に分散できているか。
  • キャッシングと遅延インスタンス化: アクセス時間を短縮するためのローカルコピーの利用や、必要な時までオブジェクトの生成を遅らせる設計(Lazy instantiation)が行われているか。
  • トランザクション制御: トランザクションの並行性が保たれ、オンライントランザクション処理 (OLTP) とオンライン分析処理 (OLAP) のプロセスが分離されているか。
  • データの複製: ボトルネックを防ぐためのデータレプリケーションが構成されているか。

コードレビューのためのチェックリストは必然的に「ローレベル」なものになり、使用するプログラミング言語に特化させたときに最も効果を発揮します。経験の浅い開発者を指導するためにも、避けるべき「アンチパターン」をリストに含めておくことが有用です。

テクニカルテストアナリスト(TTA)がコードレビューで使用すべき典型的な6つのチェックカテゴリを以下に示します。

  • 設計を完全に実装し、コーディング標準に準拠しているか。
  • 到達できないコード(デッドコード)、不要なプロシージャ、テスト用のスタブが残っていないか。
  • 共通ライブラリへの置き換えや、重複コードの統合(リファクタリング)が可能か。
  • マジックナンバー」(意味不明な定数)ではなく、シンボリックが使用されているか。

2. ドキュメンテーション (Documentation)

Section titled “2. ドキュメンテーション (Documentation)”
  • コードが明確に文書化され、コメントの内容が実際のコードの挙動と整合しているか。
  • すべての変数が意味のある明確な名前で定義され、未使用や冗長な変数が放置されていないか。
  • 浮動小数点数の「等しいかどうかの比較(==)」を避けているか。
  • 丸め誤差が防がれており、除数(割る数)が0になるケースがテストされているか。
  • 大きさが極端に異なる数値の加減算を避けているか。

5. ループとブランチ (Loops and Branches)

Section titled “5. ループとブランチ (Loops and Branches)”
  • ロジックが正しくネスト(入れ子)され、IF-ELSEIFチェーンでは「最も一般的なケース」を最初にテストしているか。
  • すべてのCASE文に「デフォルト(Default)」の処理が用意されているか。
  • ループの終了条件が明確で、必ず達成可能(無限ループにならない)か。
  • インデックス変数がループ前で正しく初期化され、ループ内で不適切に操作されていないか。

6. 防御的プログラミング (Defensive Programming)

Section titled “6. 防御的プログラミング (Defensive Programming)”
  • 配列やファイルのインデックス・ポインタが、境界値に対して安全にテストされているか。
  • インポートしたデータや入力引数の妥当性がチェックされているか。
  • 動的に割り当てられたすべてのメモリが正しく解放され、外部機器へのアクセスにタイムアウトやエラートラップが設定されているか。
  • プログラム終了時に、ファイルやデバイスが「正しい状態(クローズドなど)」で残されているか。