コードの品質を保つためのガイドライン
更新 : 2007 年 11 月
ここでは、コードの品質を保つための、さまざまなガイドラインを紹介します。
必ず行うこと
一定品質を満たしたコードしかチェックインできないようにする。
後続の製品サイクルで問題が生じるような低品質のコードはチェックインできないようにします。過度に複雑な問題、漠然とした問題、製品サイクルの終わり近くに発覚したような問題には、通常は対処できないことを理解しておく必要があります。
チェックリストを使用する。
自分が犯しやすい種類のミスは追跡してチェックリストを作成し、今後、コードを作成する際に役立てるようにします。まず、所属するグループまたは部門で見られる一般的なエラーのチェックリストを作成し、それを基に自分用のチェックリストとしてカスタマイズします。
コード レビューを実施する。
コード レビューを実施することにより、自分が作成したコードを客観的に理解し、そのコードを第三者にチェックしてもらうことができます。
単体テストを作成する。
高品質を維持するための最善の方法は、データやアルゴリズムを検証するためのテストを作成し、過去に犯した問題が再発しないかどうかを検証することです。単体テストには次の 4 種類があります。
肯定的単体テスト。想定した範囲内でコードを使用し、適切な結果が得られることを確認します。
否定的単体テスト。コードに対して意図的に想定外の使い方を適用し、コードの堅牢性が保たれ、適切なエラー処理が行われているかどうかを検証します。
ストレス テスト。コードに限界まで高い負荷をかけることにより、リソース、タイミング、関数の再入可能性などに問題が生じないかを検証します。
フォールト インジェクション テスト。エラー処理の異常を検出します。
詳細については、「方法 : 単体テストを編集する」を参照してください。
コード分析ツールを使用する。
バグを早期に発見する最も簡単な方法は、コンパイラの警告レベルを上げることと、コード分析ツールを使用することです。決して警告を無視せず、コードを修正することがきわめて重要となります。
詳細については、「C/C++ コード障害の検出と修正」および「マネージ コード障害の検出と修正」を参照してください。
不適切な言葉遣いがソース コードに入り込まないようにする。
不適切な言葉遣いや引用がソース コード内に存在していないかを確認する必要があります。世界中の顧客の多くは、社会的地位が疑われるような特定の言い回しや、人名、政治団体の引用を極端に嫌います。政治的に微妙な引用や言葉遣いが含まれていないか、ソース コードを検索し、見つかったすべてのエラーをレポートします。
作業項目を作成する。
作業を未完了のまま放置してしまうことのないよう、各種コメント (TODO、確認、バグ、UNDONE) の作業項目を必ず作成するようにしてください。詳細については、「方法 : 新しい作業項目を追加する」を参照してください。
避けるべきこと
仕様にない機能を実装する。
仕様にないコードを作成しないでください。仕様は最初に作成し、レビューしておく必要があります。仕様が決まっていないと、テスト チームが、正常な動作と異常な動作を判断できません。仕様にないコードを作成すると、チーム メンバーどうしの誤解を招くだけでなく、顧客の要求まで見落とし、低品質の製品が出荷されてしまう原因となります。詳細については、「Team Foundation のチーム プロジェクト」を参照してください。
第 1 マイルストーンの中間地点に達しても製品のセットアップができない。
テスト チームは、なんらかの方法で製品を各自のコンピュータにセットアップできることが必要です。プロトタイプ セットアップであってもかまいません。詳細については、「Team Foundation ビルドの概要」を参照してください。
お勧めすること
一貫したコーディング スタイルを用いる。
チーム全体でコードのスタイルが統一されていれば、製品として完成したコードの読みやすさ、一貫性、保守性、および、総合的な品質が向上します。ガイドラインの項目そのものは、さほど重要ではありません。より重要なことは、なんらかのガイドラインを設定し、チーム全員が忠実にそれに従うことです。コーディング スタイルを統一することで得られる最大のメリットは、コーディング パターンの一貫性が保たれ、理解しやすくなる点です。コーディング スタイルを決め、それに従うことで初めて、これが実現します。
コードを作成する前に単体テストを作成する。
テスト ファースト開発は、アジャイル開発とエクストリーム プログラミングの鍵となる手法です。単体テストを先に作成しておくことで、品質に貢献する次のようなメリットが生まれます。
利用可能な単体テストが確実に存在する。
コードを容易にテストできる。また、モジュール間の連携性を高めると共に、相互の依存度を低くできる。
どのようにテストするかを最初に検討することで、適切なデザインが判明する場合も多い。
詳細については、「方法 : 単体テストを編集する」を参照してください。
他のプラットフォームに対するコードの移植性を考慮する。
実際には他のプラットフォーム向けに出荷する予定はなくても、移植性を視野に入れたデザインとコーディングにより、コードの堅牢性を高めることができます。コードに移植性を持たせることのメリットは次のとおりです。
より優れた仮説が可能となる。
データ型およびデザイン上の意図が明確になる。
新しいプラットフォームを容易にサポートでき、将来性を確保できる。
既存のコードをより小さな関数単位へとリファクタリングする。
リファクタリングにより、既存のコードを有効活用できます。大規模な旧式のシステムを修正するとき、機能間の相互依存が複雑すぎて、コメントを変更するだけでもたいへんな苦労が伴う場合があります。
リファクタリングの効果を高めるには、初期段階で徹底した単体テストを導入し、リファクタリングで新たなエラーが発生することを確実に防ぐ必要があります。大規模な関数は、全体的な機能そのものは一切変えずに、より小さな関数単位へと分割します。この場合に従うべきガイドラインを次に示します。
ユーザー インターフェイス、データベース アクセス、COM 相互運用性を単一のインターフェイスにまとめるなど、分割した関数が、それぞれ 1 種類のタスクだけを実行するようにします。
サブシステム内のすべての関数を完全にリファクタリングした後で、システム全体に影響を与えることなく、小さく分割された個々の関数に修正を加えます。これにより、1 つの関数を 1 単位として、機能を追加、削除、強化できます。
詳細については、「クラスおよび型のリファクタリング」を参照してください。
既存のコードをレビューする。
バグは特定のモジュールに集中する傾向があります。新しいコードの完成度は高いが、古いコードの特定のモジュールにバグが多く存在している場合は、これらのモジュールだけをレビューするようにします。新しいコードが古いコードと複雑に依存し合っている場合、リファクタリングを実施することで問題を解消できます。詳細については、「C/C++ コード障害の検出と修正」および「マネージ コード障害の検出と修正」を参照してください。
すべてのコード パスをデバッガでステップ実行する。
コード検証に最適な方法の 1 つに、デバッガによるステップ実行があります。本来意図している動作を行ごとに検証します。すべてのコード パスをデバッガでステップ実行することは、単体テストを行単位で行うようなものです。決して楽しい作業ではありませんが、期待した動作を効果的に検証できます。
できれば避けること
要件文書を仕様として用いる。
要件文書を基に仕様を解釈しようとすることは避けてください。自分の解釈が、必ずしもプログラム マネージャやテスト担当者の解釈と同じであるとは限りません。解釈が違っていると、他の担当者の求める仕様を正しく実装できません。