分かった気になる静的解析


# はじめに
CI/CDツールに、静的解析ツールを入れられて、静的解析を自動で行われている方も多いと思います。
ローカルの環境で動かしてらっしゃるかもしれません。
本記事では、静的解析ツールをより上手に活用するために知っておくといいことについて、説明します。

次のような読者を想定して本記事は書いています。

■職種：プログラマ（プログラム、コードを書く人）、アーキテクト

- 最近、静的解析ツールを入れると、ソースコードの品質が上がると聞いたので、とりあえず入れてみた。
- 何だか良くなった気がするけども、更に良くするにはどうすれば？
- ソフトウェアテストについては体系的に学習したことがない。


静的解析ツールをより上手に活用するために知っておくといいことは、次の３つです。

１．ソフトウェアテストにおける静的解析の立ち位置
２．静的解析ツールの種類
３．デプロイメントパイプラインの作り込み

以降、それぞれについて説明します。

# 1. ソフトウェアテストにおける静的解析の立ち位置

ソフトウェアテストにおける静的解析の立ち位置を理解するためには、
ソフトウェアテストには、どのような種類があるのかを理解する必要があります。
（以降、ソフトウェアテストのことを、テストと呼びます。）

テストの種類を分類する方法は、様々ありますが、
今回は、ソフトウェアを動かしてテストする・ソフトウェアを動かさないでテストする
という観点で分類します。

この観点で分類したテストのことを、
一般的に、動的テスト・静的テストと呼びます。

動的テストは、ソフトウェアを動かして行うテストです。
静的テストは、ソフトウェアを動かさずに行うテストです。

静的テストをさらに分けると、静的テストは、レビューと静的解析ツールを利用する方法に分類できます。
（もちろん、動的テストもさらに分けることができます）

ここまでの話を図式化すると次の様になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/42567/bff5635e-3a11-ff1b-c53e-1af1004120f7.png)

静的解析は、静的テストの一部です。

静的テストは、人によるレビューと、静的解析ツールを利用するものに分けることができます。
静的テストは、ソフトウェアが出来上がる前にテストを行うことができるため、
動的テストよりも早くバグを見つけることができ、静的テストで見つける方が、修正にかかるコストを小さくできます。
（ライセンス費がとても高い、静的解析ツールがあるため、状況によって高くなることもありますが、基本的にコストを小さくできます）

# 2. 静的解析ツールの種類

静的解析ツールは、コード静的解析ツール、コードチェックツール、Linter、リントツール、静的解析器などと呼ばれます。
日本では、静的解析ツールと表記されることが最も多いと思います。
英語だと、Static Program Analysis Tool、Static Code Analysis Toolと呼ばれます。

静的解析ツールは、
構文木を解析し、特定のパターンに一致したものを見つけるアルゴリズムが基本的なものでした。
しかし、最近では、AIのアルゴリズムを利用したものもできてきました。

ライセンス形態は、ツールによって様々あります。料金も様々です。
無料のもの、有料のものがあります。
とても高い（数百万単位）料金のものもあります。

## 2-1 従来の静的解析ツール
従来の静的解析ツールは、２つの種類のものがあります（伝統的な静的解析ツールと呼ばれることもあります）。
コーディング規約やコーディング作法と呼ばれるものと一致しているかチェックするツールと、
脆弱性になりうるもの、パフォーマンスを落とすもの、メモリリークを引き起こすものなどのバグになりうる問題のある箇所を見つけるためのツールです。


### コーディング規約違反チェックツール
独自のコーディング規約を定義し、そのルールに違反していないかチェック、
MISRA-C、CERT-Cなどの定義されたコーディングルールに違反していないかチェックなどを行うツールです。
括弧やスペースの使い方などのスタイルを統一するような機能がメインのツールたちです。
これらのツール群は、フォーマッターと呼ばれることも多いです。

代表的な例、CheckStyle、Prettierなど

（MISRA-CやCERT-Cのコーディングルールに違反しているものを見つけるツールは、バグも見つけているため、バグになりうる問題のある箇所を見つけています。）

### バグになりうる問題のある箇所を見つけるためのツール

NullPointerなどメモリに関する問題を引き起こす箇所や
クロスサイトスクリプティングなどの脆弱性に関する問題を引き起こす箇所を見つけるツールです。

代表的な例、SpotBugs、ESlint、Fortify、Coverityなど

どのような静的解析ツールがあるかは、下記を見るとよくまとまっていて参考になります。
https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis


### 2-2 モダンな静的解析ツール

最近はAIのアルゴリズムを利用するものが増えてきました。
AIのアルゴリズムを利用することで、今までには見つけることのできないものも見つけることができるようになりました。

できることは、従来の静的解析ツールとあまり変わりません。
実装方法のアルゴリズムがAIと呼ばれる方法に変わっているだけです（たぶん）。
大きく変わることは、状況に基づいた修正方法の提案を行うことができるようなる点だと思います。

代表的な例：Amazon CodeGuru、GAMMAなど

# 3.デプロイメントパイプラインの作り込み

デプロイメントパイプラインは、CI/CDパイプラインと呼ばれることも多いです。
どちらも同じことを意味する言葉として使われています。
デプロイメントパイプラインは、プロダクトを開発してからデプロイするまでの流れのことです。
できるだけ、自動化していく必要があります。
デプロイメントパイプラインは、CI/CDツールと呼ばれるツール群（Jenkins、CicrleCI）を利用して、構築し、自動化していきます。

詳しくは、下記の資料をご覧ください。
https://itnews.org/news_contents/cicd-pipeline/
https://bliki-ja.github.io/DeploymentPipeline/

デプロイメントパイプラインは、静的解析ツールをCI/CDツールに導入することはもちろんのこと、
パフォーマンステスト、動的セキュリティテスト、UIのテストなども、自動化の手段を考えて、作り込んでいく必要があります。
テストを実行する順番も考える必要があります。初めは、全て自動化しなくてもいいと思います。
一つのツールで、全てをできるツールはありません。
ツールでできること・できないことを考えて、デプロイメントパイプラインを作り込む必要があります。
デプロイメントパイプラインを作り込むことで、ソフトウェア開発の速度を上げていくことができます。


# さいごに

ソフトウェアテストの分類は様々あります。
静的解析ツールの分類も様々あります。
個人的にわかりやすい分類で解説しました。

皆様の開発ライフが、ハッピーになれば幸いです。