バグを作りこまないために

バグとは想定した動作を妨げる実装が含まれていることを指すと考える。すると、想定した振る舞いとその確認が過不足なく行われていればよいことになる。これは、その機能の仕様が明確であり、確認した結果と共に証拠として残っていることと言いかえることができる。

そして新たなバグの発生を未然に防ぐ意味では、ソースコードの現状がより把握しやすくなっていることが求められるだろう。ソースコードが読みやすいか、そして変更しやすいか、ということだ。

そのためには、コーディング上の規約やプラクティスに準拠したソースコードを記述しているかを確認する必要がある。また、ソースコードの依存関係や実装コードの入れ子などの複雑さ（サイクロマティック複雑度）が把握できれば、そのソースコードの変更の覚悟を事前および事後に確認することができるだろう。

前者はソースコードを実行することで確認することから動的な確認となり、後者はソースコードの状態で確認することから静的な確認となる。

これらを整理すると、バグを作りこまないためには「仕様通りの実装かどうか振る舞いの確認とその網羅性（単体テストとコードカバレッジ）」「コーディングのプラクティスへの準拠の確認（静的コード分析）」「ソースコードの複雑さの把握（コードメトリックス）」を考慮する必要があると言える。

開発支援ツールによる省力化と自動化の効果

これらの作業を手作業で実施するのはどうか。手作業では、開発者の負担が大き過ぎるといえる。また手作業では、作業のミスによる確認や検証自体の信頼性の低下を招くかもしれない。逆説的にいうと、開発者にとってこれらの作業の負担が大きいため、統合開発環境でサポートしている範囲での検証や確認作業に留まっているのではないだろうか。

これらは開発支援ツールでその多くがサポートされている。例えば、コーディングのプラクティスに準拠しているかを確認するならば、静的コード分析ツールが役に立つだろう。変更しやすいかどうかを事前に知った上で変更作業が行えるようにするには、コードメトリックスツールが使えるだろう。

仕様通りの振る舞いをしているかどうかは、単体テストフレームワークが効果的である。コードカバレッジツールと併用することで、単体テストの網羅性も把握できるだろう。

これらを組み合わせて活用し、例えば注目の設計・開発手法であるテスト駆動開発（TDD：Test Driven Development）を実践するのもよい方法であろう（本記事ではTDDの説明は割愛する）。

このように、そのほとんどが開発支援ツールとして提供されており、Visual Studioのような統合開発環境の機能とそれらを用いることで、バグを作りこまないための作業の多くを省力化、自動化することができる。

これらの開発支援ツールを選定する場合の1つの目安としては、それが開発チームで統一して利用していくことができるのかということや、利用が定着するのかを考慮してほしい。1人の開発者や数人のメンバーだけが利用し、他の開発者が利用しないということでは、バグを作りこまないための施策としては不十分だと言わざるを得ない。 次のページ