コラム

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

グーグルのクラウドを支えるテクノロジー

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第43回　Googleにおける静的コード解析ツールの活用（パート1） (中井悦司) 2018年8月

はじめに

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

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

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

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

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

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

　そして、次の試みとして、既存のコードレビュープロセスにツールを組み込むということが行われました。第42回の記事で説明したように、Googleでは、専用のツールを用いたコードレビューが行われます。コードのレビュー依頼が登録されたタイミングでレビュー対象のコードをFindBugsで解析し、発見された問題点をレビューコメントとして自動的に表示する仕組みを構築したのです。既存の開発プロセスの中に、ツールのチェック結果を自然に組み入れるという発想ですが、この方策はうまく行ったのでしょうか？　―― 残念ながら、これもまたうまく行かなったそうです。表示された問題点には、実際には対応が不要なものも多かったため、開発者は、次第にFindBugsのコメントそのものを無視するようになってしまったのです。2011年にコードレビューツールの更新が行われた際に、結局、この仕組は取り除かれることになりました。

ビルドプロセスと静的コード解析ツールの統合

　Javeコードの静的解析ツールの活用がうまく進まない中、C++のコンパイラであるClangコンパイラの開発チームは、静的コード解析の仕組みをコンパイラの機能として取り入れるという試みを進めていました。ソースコードをビルドするタイミングで静的コード解析も同時に行い、重要な問題を発見した際は、修正案を表示するとともに、ビルドそのものを失敗させるのです。この方法であれば、開発者はその問題を無視することはできません。ビルドを成功させるためには、必ず、その問題を修正する必要があります。

　また、新たなチェック項目を導入する際は、事前にリポジトリ内のコードすべてにバッチでチェックを行い、既存のコードにおける問題の有無を確認します。発見された問題については、該当するコードの開発チームにチェック結果を提示して、それが本当に修正する必要があるものかを確認します。このようにして、それぞれの開発チームが同意して、既存の問題がすべて修正された後に、そのチェック項目をコンパイラに組み入れます。これにより、開発者が不要と感じる、無意味なチェック項目の導入を回避することができるというわけです。

　Javaコンパイラの開発チームは、この手法をまねて、Javaコンパイラに静的コード解析の機能を追加することにしました。この際、前述のClangコンパイラの場合と同様に、事前にリポジトリ内のすべてのコードにバッチでチェックを行い、発見された問題を該当するコードの開発チームに修正するよう依頼しました。このプロセスに関する開発チームからのフィードバックはおおむね良好で、「作業が増えて忙しくなった」というネガティブな反応は、2%ほどだったということです。また、開発チームからの同意が得られたチェック項目のみを有効化することにより、開発者にとっても意味のあるコード解析ができるようになりました。

次回予告

　今回は、2018年に公開されたエッセイ「Lessons from Building Static Analysis Tools at Google」をもとにして、Googleのソフトウェア開発プロセスにおける、静的コード解析ツールの活用例を紹介しました。当初は、独立した解析ツールを導入しようとしたものの、既存の開発プロセスとの統合がうまく進みませんでしたが、その後、コンパイラに静的コード解析の機能を追加するという方法でうまく開発プロセスに統合することができました。

　次回は、このようにして導入された静的コード解析ツールの有効性、あるいは、開発者にとって意味のある解析を行うための注意点など、このプロセスを通して得られた知見を紹介したいと思います。

Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡