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

私がCTC教育サービスで編集支援しているグーグルのクラウドを支えるテクノロジー第44回が公開されました。

「Googleにおける静的コード解析ツールの活用（パート2）」

興味がある方はご覧ください。

＃＃＃

はじめに

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

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

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

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

この続きは以下をご覧ください
https://www.school.ctc-g.co.jp/columns/nakai2/nakai244.html