静的コード・チェックの運用例

作業時間や作業負荷が少なくて済むなど、少ない実行コストでツールを運用できると、開発の早期から導入し、繰り返して利用できるようになります。実際に、どのような運用が可能になるのかを、モデル・ケースを例に説明します。

静的コード・チェックの運用例

静的コード・チェック・ツールに限らず、運用上のコストは重要です。品質の向上にとって継続的なツールの使用は欠かせませんが、この一方で、ツールの実行に多くの人手をかけることはできません。

図3は、静的コード・チェック・ツールを導入する場合の構築例です。開発者のPCのほかに、構成管理サーバー、CodeDirectorを導入したインスペクション・サーバー、で成り立っています。運用の流れは、以下の通りです。

1. 開発者が、構成管理サーバーにソースを登録する。
2. インスペクション・サーバーは、定期的にCodeDirectorを起動する。
3. CodeDirectorは、構成管理サーバーから最新のソースを取得し、検査する。
4. 開発者は、結果を参照して、必要な修正を行う。
→1. から繰り返す。

実際に開発者の作業が入るのは、上記の（1.）と（4.）だけです。（1.）は、開発における通常作業であると想定できるため、増えるのは実質、（4.）の結果の確認だけです。開発の早期から品質改善のフィード・バック・ループを構築することで、従来であればテスト工程以降で発生するはずだった不具合をコーディング工程で発見／対処する体制を作ることができます。

重要なポイントは、早い段階でツールを使い始めることが良い効果をもたらすということです。加えて、ツールを適用するかどうかは、運用のコストが重要になってくるということです。

早い段階でツールを適用することで、不具合を作りこみにくいソース・コードを記述できるので、不具合そのものを減らすことができます。逆に、ある程度開発が進んでしまってからツールを使い始めると、修正ができなくなり、不具合が潜む温床として残ってしまいます。

プロジェクトの特性も見えてくる

静的コード・チェック・ツールでプロジェクトをまとめて検査すると、プロジェクトの特性が見えてきます。特に、ツールから指摘を受けやすいパターンと、そうでないパターンを、明確に区別できるようになります。CodeDirectorは、分析機能が充実しているため、管理者と開発者、それぞれのレベルで状況の把握ができます。

「致命的でない指摘であれば、プロジェクトの特性として許容し、検査対象から外す」といったように、チューニングの指標にもなります。これにより、「ツールから、余計な指摘ばかりされる」という不満の声も減るのではないでしょうか。

まとめ

コスト・ダウンが叫ばれる中、人と時間を確保することが難しくなっています。こうした状況下でソフトウエアの品質を確保するためには、ツールの活用が不可避です。今回は、静的コード・チェック・ツールを紹介しました。

プロジェクトの特性などは、実際にツールを実行しないと分かりません。CodeDirectorでは、会員登録だけで使える無償の体験版もダウンロード配布しています。静的コード・チェック・ツールがどのようなものか、触れてみてはいかがでしょうか。