SonarQubeの静的解析を構成する概念について

# 概要
## 前提
- SonarQubeを使ってPHPプロジェクトの解析をやっていこう
- 概念的な部分の整理を兼ねてこの資料を書いた
- 個人の見解を含みます
- 詳しい情報については最新のドキュメントを読んでください

## 構成概念
SonarQubeの静的解析は、以下2つの概念で構成されている。
- Rule
- Quality Profile

また、Ruleと密接に関連する概念として、Issueがある。RuleとIssueを理解すると、SonarQubeの画面の操作などの理解がスムーズになるので、本稿では前述2つの概念に加えて、Issueについても取り扱う。

## 要約
### RuleとQualityProfileの関係について
- 「認知的複雑度が15以上のメソッド禁止」等、具体的なコード解析内容を定義したものがRuleである。
- Quality ProfileはこれらRuleを複数束ねた集合であるとともに、Ruleごとの設定値を管理するためにも利用される。
    - 一例として、「認知的複雑度のしきい値を15から10に変更したい」という場合、しきい値「10」は、Quality Profileに紐づける形で管理される。


### Issueについて
- コード解析は、Quality Profileで定義された内容に従って行われる。
- Quality Profileに紐付けられた各Ruleは、Ruleの条件に該当する場合にIssueを発行する。
- 開発チームは、発行されたIssueを1つのタスクとして解決することで、コード品質を改善することができる。

# 各概念の詳細
## Quality Profile
https://docs.sonarqube.org/latest/instance-administration/quality-profiles/

> Quality profiles are a key part of your SonarQube configuration. They define the set of rules to be applied during code analysis.

- デフォルト状態ではSonar wayというQualtyProfileが適用された状態となっているため、何かカスタマイズを行いたい場合は新たにQuality Profile を作成する必要がある。
- Quality Profileを作成する場合、複製と継承を選ぶことができる。
- とりあえずいじりながら様子を見たいのであれば継承の方が楽。

## Rule
https://docs.sonarqube.org/latest/user-guide/rules/overview/
- Ruleは、SonarQubeにおけるコード解析設定の最も小さい単位である（たぶん）
- コード解析実行時、コードをRuleが検査し、結果に従ってIssueが作成される。
- Ruleにはいくつかの属性がある。主なものを以下に挙げる。
    - Language: どの言語に適用されるルールか。
    - Type: このルールが発行するIssueの種類。
    - Default Severity: このルールが発行するIssueのデフォルトの重大度。
- SonarQubeの解析設定周りの概念は、オブジェクト指向的な設計になっている。
    - 初期状態では、管理画面上の「Rules」から入っても、Ruleそのものを変更することはできない。
    - プロジェクトごとにRule設定を微調整したい場合は、以下の手順を取る。
        - 「Quality Profiles」の画面へ遷移する
        - 各言語用に用意されているデフォルトのQuality Profile（Sonar way）を継承して、自分専用のQuality Profileを作成する
        - Quality Profile作成後、「Rules」の画面から設定を調整したいRuleの画面へ遷移
        - Ruleのパラメータ、スレッショルド、属性をプロジェクトに合わせて調整し、保存する。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/77380/6a6411e1-c0a9-1970-8aed-f1b5b3bf9d9b.png) 
※この例は「CustomPhp」というQualityProfileを作成してからRuleの詳細画面を表示したところ。CustomPhpの右に「Change」ボタンが表示されるので、ここを押すとルールの詳細を変更することができる。

- 独自にRuleを作成したい場合、プラグインを開発する必要がある。プラグインはJAVAで書く。（他にも方法があるようだが詳しく読んでない）
    - Ruleを追加する方法について [https://docs.sonarqube.org/latest/extension-guide/adding-coding-rules/](https://docs.sonarqube.org/latest/extension-guide/adding-coding-rules/)
     - PHPのソースコード解析について（PHP解析用のプラグインを開発する人向けドキュメント） [https://docs.sonarqube.org/latest/analyzing-source-code/languages/php/](https://docs.sonarqube.org/latest/analyzing-source-code/languages/php/)

## Issue
https://docs.sonarqube.org/latest/user-guide/issues/

### Issue Types
Issueの種類。4種類ある。

- Code smell (保守性)
- Bug (信頼性)
- Vulnerability (脆弱性)
- Security hotspot (脆弱性)

※ドキュメント上では3種類記載されている箇所と4種類記載されている箇所がある。管理画面上のレイアウトにおいてSecurity hotspotだけちょっと扱いが異なるようだが、概念としては4種類と考えて差し支えなさそう。

### Issue severity
重大度。5段階存在する。
- BLOCKER: Bug with a high probability to impact the behavior of the application in production. For example, a memory leak, or an unclosed JDBC connection are BLOCKERs that must be fixed immediately.
- CRITICAL: Either a bug with a low probability to impact the behavior of the application in production or an issue that represents a security flaw. An empty catch block or SQL injection would be a CRITICAL issue. The code must be reviewed immediately.
- MAJOR: A quality flaw that can highly impact the developer's productivity. An uncovered piece of code, duplicated blocks, or unused parameters are examples of MAJOR issues.
- MINOR: A quality flaw that can slightly impact the developer's productivity. For example, lines should not be too long, and "switch" statements should have at least 3 cases, are both be considered MINOR issues.
- INFO: Neither a bug nor a quality flaw, just a finding.


# 最後に
- 開発担当としては、IssueとRuleについて読んでおけばSonarQubeの画面を見るのにそんなに困らないはず。
- 品質管理担当としては、この資料の内容だけだとやや不十分かも。（他に、QualityGateの概念と、ProjectSettingsでできることを把握しておく必要があるが本稿では割愛）