オージス総研さんで、Coverity に関するセミナーがありましたので参加してみました。
Coverity が解析の対象とするソースコードは、
C/C++, C#, Java, Javascript, PHP, Python, ASP.NET, Obj-C, JSP
ということで、今回のセミナーは、組み込みシステムの品質を改めて考える、という趣旨のものでした。
Coverity の存在自体はかなり昔から知っていました。昔いた会社の、issue tracking system のなかに、あるとき、エンジニアの誰かから issue が山ほど登録されたことがあって、なんだこれはと思って見てみたら、どうやら Coverity というツールからのエラーのようでした。評価ライセンスか何かを借りて既存のコードにかけてみたんだな、と思った。というのが最初でした。
Coverity は、静的解析ということで、単なるコーディングスタイルチェック、リントチェックと思われがちですが、もっと深く解析できてバッファオーバーフローとか、ヌルポインタアクセスとか、まあ、結構やらかしてしまいそうなところはちゃんとチェックしてくれるようです。ソースコードレビューなんかやっても、コードのこの辺がやばそうだから集中的にチェックするとか、絞り込みがあらかじめできていないと、なかなか問題発見とはいかないものだと思います。
個人的な経験では、ライブラリ化して長年使っているブロックが、あるプロジェクトで急に不具合の原因になったということがありました。そのプロジェクトでの使われ方でのみ発生する不具合だったのですが、そのライブラリはもうOKだと思って調査せずに他を部分を調べていて、原因究明にすごく時間がかかったということがありました。しかもその原因を見つけたのがお客さんだったという無様な結果でした。こういうのも、使っているコード全部に厳しく解析をかけて、エラーを確認していくというプロセスが一度でもあれば、と思ったことがあります。
ツールとしては、いいと思いますね。本当に大規模なコードになれば、こういうのは導入すべきだと思います（直近自分には関係ないのですが）。こういうツール導入に躊躇するマネージャは目先のお金しか見えてなくて、トータルでモノを考えられない、人間のワークライフバランスなど考えが及ばない昭和なスタイルだと思いますね。どういうところにどういうツールを活用しているか、をみることで、マネージャもしくはその会社の価値観・スタンスが分かります。
もちろん導入すれば何でもハッピー、ではなくて、吐き出されたエラーにたいして実施された修正内容を他者がレビューするなどのフローをちゃんと作っておくとか、エラーでなければ万事OKというわけではなく、そもそもの設計仕様まで見てくれるわけではないので、人間がやるべきところをちゃんと認識しておく必要はあります。
