グーグルのクラウドを支えるテクノロジー　＞　第43回　Googleにおける静的コード解析ツールの活用（パート1）

CTC教育サービスはコラム「グーグルのクラウドを支えるテクノロジー　＞　第43回　Googleにおける静的コード解析ツールの活用（パート1）」を公開しました。

＃＃＃

はじめに

　今回は、2018年に公開されたエッセイ「Lessons from Building Static Analysis Tools at Google」をもとにして、Googleのソフトウェア開発プロセスにおける、静的コード解析ツールの活用例を紹介します。

　静的コード解析ツールというのは、プログラムを実行することなく、ソースコード（場合によってはコンパイル済みのバイナリーコード）の内容を一定のルールに従って解析するもので、文法上の問題に加えて、潜在的な不具合を発見することができます。数年前、ある商用ソフトウェアのソースコードに、「goto fail;」という行が誤って2回続けて書かれていたというバグが話題になったことがありますが、このような単純ミスは、静的コード解析ツールによって発見することができます。

静的コード解析ツールの導入実験例

　ソフトウェアの開発プロセスにおいて、静的コード解析ツールを用いたチェックを行うタイミングには、いくつかのパターンが考えられます。Googleでは、当初、Javaコードの静的解析ツールとしてFindBugsを使用しており、冒頭のエッセイでは、これを開発プロセスにどのように組み込むべきかという点について、いくつかの実験を行ってきたことが紹介されています。

　たとえば、2006年には、最初の試みとして、「バグダッシュボード」がソフトウェア開発者に提供されました。これは、コードリポジトリに保存されたすべてのソースコードについて、夜間バッチで一斉にチェックを行うという仕組みです。発見された問題点は、専用のダッシュボードで確認することができます。しかしながら、実際にこのダッシュボードを運用したところ、その結果は残念なものとなりました。ダッシュボードには数百もの問題点が登録されているにも関わらず、わざわざそのダッシュボードを見にいく開発者は、ほとんどいなかったのです。これは、通常の開発プロセスの中に、ダッシュボードを見るという作業が組み込まれていなかったことが原因です。通常の作業を妨げることなく、自然な形でツールが利用される環境が必要だったというわけです。

　そこで、次の試みとして、2009年に、ツールが発見した問題点を集中的にチェックする「Fixitウィーク」が開催されました。ここでは、専任のチームがダッシュボードに登録された問題を確認して、対応の優先順位付けを行いました。そして、数百名規模の開発者に呼びかけて、優先度の高い問題を集中的にチェックする、一種の社内イベントを開催したのです。しかしながら、こちらもまた、結果は満足の行くものではありませんでした。優先度が高いと判断された問題の多くは、理屈上は、確かに問題のあるコードなのですが、その大部分は、実用的にはクリティカルなものではありませんでした。この期間に実際に修正が行われたのは、発見された問題の約16%にすぎなかったそうです。人手で優先順位付けを行うというのは、やはり、非効率的で、大規模に展開するのは難しいということがわかりました。

この続きは以下をご覧ください
(リンク »)