グーグルのクラウドを支えるテクノロジー > 第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

この記事が役に立ったらシェア!
みんなが読んでるWeb担メルマガで、あなたも最新情報をチェック
  • SEOやデジタルマーケの最新情報をゲット
  • 事例やインタビューも見逃さない
  • 要チェックのセミナー情報も届く
みんなが読んでるWeb担メルマガで、あなたも最新情報をチェック
  • SEOやデジタルマーケの最新情報をゲット
  • 事例やインタビューも見逃さない
  • 要チェックのセミナー情報も届く

Web業界の転職情報

もっと見る
Sponsored by

今日の用語

Google爆弾
Googleに限らず、検索エンジンでネガティブな言葉を入力すると特定のホームペー ...→用語集へ

連載/特集コーナーから探す

インフォメーション

RSSフィード


Web担を応援して支えてくださっている企業さま [各サービス/製品の紹介はこちらから]