IT・技術研修ならCTC教育サービス

サイト内検索 企業情報 サイトマップ

研修コース検索

コラム

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

CTC 教育サービス

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

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

はじめに

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

 前回の記事では、Javaコードの静的解析ツールを導入するにあたり、Javaコンパイラによるビルド処理に静的コード解析の機能を追加するという方針に至る経緯を紹介しました。この機能拡張モジュールは、現在、Error Proneという名称のオープンソースソフトウェアとして公開されています。今回は、Googleの開発プロセスにおけるError Proneの活用方法、そして、そこから得られた知見などを紹介したいと思います。

Error Proneを用いた開発プロセスの特徴

 Error Proneは、ソースコードをビルドする際に静的コード解析を行い、問題を発見した場合はビルド処理を失敗させるという動きをします。実際の開発プロセスにおいては、開発者がコードレビューを依頼した際に自動ビルドが行われるので、このタイミングでError Proneによるチェックが行われます。これは、リポジトリにコミットされたコードに対して、後からバッチで解析するよりも好ましい動作と考えられます。コードレビューの過程では、人間のレビュアーによるチェックが行われるため、このような人間の目によるレビューの後に、ツールによる自動チェックを行っても、人間の負担を軽減することにはなりません。また、コードレビュー開始時と終了後では、開発者のマインドセットも異なります。コードレビュー開始時は、自身のコードを批判的に見て、さまざまな修正案を前向きに検討することができます。しかしながら、すでにレビューを完了したコードに対して後から問題点を指摘されると、「余計な仕事を増やされた」という後ろ向きな気持ちになることもありえます。前回紹介した、「バッチで発見した問題をダッシュボードに登録する」という手法が開発者に受け入れられなかった背景には、このような心理的な要因もあったものと想像されます。

 また、Error Proneが問題を発見すると、そのコードのビルド処理が失敗するので、ビルド後のテスト処理を成功させてコードをコミットするには、Error Proneが発見した問題は必ず解決する必要があります。したがって、Error Proneが報告する問題には、一定の基準が必要となります。「実際には解決する必要がない」、あるいは、「そもそも解決方法が存在しない」といった問題によってビルドが失敗すると、開発者に余計な負担を強いることになるからです。そこで、Error Proneが問題を報告する際は、それが問題と言える理由、そして、具体的な修正案をあわせて提示します。また、かならずしも解決する必要がない警告レベルの問題については、ビルドは失敗させず、コードレビューツール上に参考コメントを表示します。レビュアーは、これらの中で、実際に修正が必要と思われるものがあれば、開発者に修正を依頼することができます。

静的コード解析ツール活用のポイント

 冒頭の論文では、Error Proneの導入にいたる経験から得られた教訓がまとめられています。これまでの説明と重複する部分もありますが、特に興味深い点をあげると、次のようなものがあります。

 まず、Googleのリポジトリには、20億行を超えるソースコードが保存されており、これまでに、3,500万回を超えるコミットが行われてきました。この膨大なコードヒストリーの中には、想像し得るほとんどのパターンの「バグ」が含まれていると考えられます。Error Proneに新たな問題のパターンを登録する際は、この膨大なコードヒストリーを用いることで、適切なチェック方法、あるいは、修正案を見つけ出すことが可能になります。

 また、発見した問題を開発者に伝えるには、適切なタイミングを考える必要があります。先に触れたように、レビューが終わってコミットが完了したコードに対して、後から問題点を指摘しても、もはや手遅れです。開発者に余計な負担を強いるのではなく、あくまでも、開発者の生産性を高めるためのツールとして認識してもらうことが大切です。問題点を指摘するだけではなく、適切な修正案をあわせて提示するというのも、同様のポイントと言えるでしょう。

次回予告

 今回は、2018年に公開されたエッセイ「Lessons from Building Static Analysis Tools at Google」をもとにして、Googleにおける静的コード解析ツールの活用例、そして、そこから得られた「活用のポイント」を紹介しました。

 次回は、すこし話題を変えて、スマートフォンに代表されるモバイル端末、特に、そのハードウェアに関する話題をお届けしたいと思います。

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

 


 

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