本書を手に取られたあなたは「限られた工数の中で、ソースコードの品質が高い状態」を作りたいと考えられているのではないでしょうか？そして、ソースコードの品質が高い状態を作るためには、「バグを早期に発見すること」を可能にするテストツールをお探しだと思います。しかし「バグを早期に発見すること」だけに着目してテストツールを利用すると、ソースコードの品質が高い状態を作ることが難しい場合があります。

ソースコードの品質が高い状態を作るためには、次の2つが必要です。

• バグの「種類」を区別して適切なアプローチで、バグを検出する環境

• コードの修正作業を妨げる開発現場の「悪い習慣」を防止する仕組み

もう少し詳しく見ていきましょう。

このページの内容:

バグの種類と検出するためのアプローチ

ソフトウェアのバグは大きく分けて３種類に分けられます。これらのバグの原因は、依存している箇所が異なります。
つまり、それぞれのバグには、検出するための最適なアプローチがあります。

アプローチを間違えてしまうといくら工数・コストをかけてもバグを検出できなくなります。今、現場で発生しやすいバグの種類を確認し適切なアプローチを行いましょう。

コードの修正作業と作業を妨げる開発現場の「悪い習慣」

バグ発見時のコードの修正作業手順を改めて確認しましょう。

1. バグの発見

2. バグの原因の特定

3. 現状のコードの分析

4. 再設計

5. コーディング

6. バグがなくなった事の確認

発見されたバグ毎に、上記の作業を実施しないとバグが減っていく事はありません。バグが減らなければ、品質が上がる事はありません。そのため、品質を上げるためにはコードの修正作業の「回数」と「量」を「少なく」することが重要になります。もしも静的解析ツールを利用しているのに、コードの品質が上がらない場合、開発現場に修正作業を妨げる「悪い習慣」が要因となり、バグが減らないといった現象が発生します。

そんな「悪い習慣」をご紹介しましょう！

コードの修正作業を妨げる「悪い習慣」

悪い習慣１　 コードの可読性・拡張性を考慮してコーディングしていない

コードの可読性・拡張性が低い場合、コード分析・再設計により多くの時間を要します。いくらバグを早期に発見したとしても、一回のコード修正作業時間が伸びてしまいます。結果として、全体の修正作業量が増え、バグが減らない状況を作り出します。

悪い習慣２　過去のバグを防止するためのコーディングルールを用意し、開発者にルール遵守を徹底させていない

いくらバグを早期に発見したとしても、過去のバグを防止していなければ、コードの修正や仕様変更の度に、デグレードを起こす可能性は非常に高くなります。デグレードを起こしてしまうと、再度コードの修正作業が発生します。結果として、全体の修正作業量が増え、バグが減らない状況を作り出します。

悪い習慣３　コピーコードを利用してしまうことが多い

バグが存在するコードのコピーが存在する場合、そのコピーコードはバグ、もしくはデグレードの可能性が高いコードになります。そのため、コピーコードが多い場合、バグの早期発見漏れの可能性を高め、かつコード修正作業を増やす原因となります。

悪い習慣４　コードを複雑に書いても気にしない

コードが複雑な場合、コード分析・再設計により多くの時間を要します。また、単体テストにおいては、テストケース作成以前にテスト設計が困難になり、結果として単体テストを実施できない状態になります。この状態では「仕様に対するバグ」の早期発見を不可能にします。

C/C++testとは

C/C++testは、無数にあるC/C+言語ソフトウェア開発環境に対し、以下2つを実現します。

• バグの「種類」を区別して適切なアプローチで、バグを検出する環境

• コードの修正作業を妨げる開発現場の「悪い習慣」を防止する仕組み

そのため、C/C++testは静的解析・動的解析といった多くの機能を搭載しています。

Open

本書では、静的解析機能を中心に操作方法・運用ポイントを紹介していきます。

Open

動的解析機能にご興味のある方は、別途チュートリアルをご用意しております。 ご興味のある方は、テクマトリックスまでご連絡ください。