本書を手に取られたあなたは「限られた工数の中で、ソースコードの品質が高い状態」を作りたいと考えられているのではないでしょうか?そして、ソースコードの品質が高い状態を作るためには、「バグを早期に発見すること」を可能にするテストツールをお探しだと思います。しかし「バグを早期に発見すること」だけに着目してテストツールを利用すると、ソースコードの品質が高い状態を作ることが難しい場合があります。
ソースコードの品質が高い状態を作るためには以下の2つが必要です。
バグの「種類」を区別して適切なアプローチで、バグを検出する環境
コードの修正作業を妨げる開発現場の「悪い習慣」を防止する仕組み
もう少し詳しく見ていきましょう。
バグの種類と検出するためのアプローチ
ソフトウェアのバグは大きく分けて3種類に分けられます。これらのバグの原因は、依存している箇所が異なります。
つまり、それぞれのバグには、検出するための最適なアプローチがあります。
バグの種類 | バグが依存している箇所 | バグ検出最適アプローチ |
---|---|---|
メモリ破壊などを引き起こすプログラム | プログラミング言語の仕様 | 静的フロー解析 |
仕様に対するバグ | 開発製品の仕様 | 仕様を基準に動作確認を行う単体テスト |
ソフトウェアを実装する環境上で発生するバグ | 実装するハードウェア・ペリフェラル | 実装環境上での単体テスト |
アプローチを間違えてしまうといくら工数・コストをかけてもバグを検出できなくなります。今、現場で発生しやすいバグの種類を確認し適切なアプローチを行いましょう。
コードの修正作業と作業を妨げる開発現場の「悪い習慣」
バグ発見時のコードの修正作業手順を改めて確認しましょう。
バグの発見
バグの原因の特定
現状のコードの分析
再設計
コーディング
バグがなくなった事の確認
発見されたバグ毎に、上記の作業を実施しないとバグが減っていく事はありません。バグが減らなければ、品質が上がる事はありません。そのため、品質を上げるためにはコードの修正作業の「回数」と「量」を「少なく」することが重要になります。もしも静的解析ツールを利用しているのに、コードの品質が上がらない場合、開発現場に修正作業を妨げる「悪い習慣」が要因となり、バグが減らないといった現象が発生します。
そんな「悪い習慣」をご紹介しましょう!
コードの修正作業を妨げる「悪い習慣」
悪い習慣1 コードの可読性・拡張性を考慮してコーディングしていない
コードの可読性・拡張性が低い場合、コード分析・再設計により多くの時間を要します。いくらバグを早期に発見したとしても、一回のコード修正作業時間が伸びてしまいます。結果として、全体の修正作業量が増え、バグが減らない状況を作り出します。
悪い習慣2 過去のバグを防止するためのコーディングルールを用意し、開発者にルール遵守を徹底させていない
いくらバグを早期に発見したとしても、過去のバグを防止していなければ、コードの修正や仕様変更の度に、デグレードを起こす可能性は非常に高くなります。デグレードを起こしてしまうと、再度コードの修正作業が発生します。結果として、全体の修正作業量が増え、バグが減らない状況を作り出します。
悪い習慣3 コピーコードを利用してしまうことが多い
バグが存在するコードのコピーが存在する場合、そのコピーコードはバグ、もしくはデグレードの可能性が高いコードになります。そのため、コピーコードが多い場合、バグの早期発見漏れの可能性を高め、かつコード修正作業を増やす原因となります。
悪い習慣4 コードを複雑に書いても気にしない
コードが複雑な場合、コード分析・再設計により多くの時間を要します。また、単体テストにおいては、テストケース作成以前にテスト設計が困難になり、結果として単体テストを実施できない状態になります。この状態では「仕様に対するバグ」の早期発見を不可能にします。