SonarQubeのQuality Gatesの設定値を考えてみた

投稿日: 投稿者: daipresents (Dai Fujihara)
inspected-with-SQ-256


ソース静的解析ツール「SonarQube」は「Quality Gates」という、コードレベルの品質基準を設定できます。ただ、どういった値を設定すればいいか？ 悩ましいところなのでいろいろ調べて自分なりの基準を考えてみました。

Quality Gatesの魅力

quality-gates

Quality Gatesの魅力。それはずばり、基準値ができることだと思います。SonarQubeによってソースコードレベルで解析が行われ、コードカバレッジ、ソースの重複度、複雑さといったデータがわかるようになれば、次はそのデータをどう扱うかがポイントになるはずです。

周囲でSonarが流行っていたときに感じたのですが、解析結果がグラフィカルに確認できるようになったのに、「で、どうしようか？」と困っている雰囲気がありました。確かに、「Complexity 8.2」って言われても、それがいいのかわるいのかよくわからない。

だから、得たデータを有効活用するために、ある程度の基準を定める必要が出てきます。その基準が「Quality Gates（日本語だと「品質基準」がわかりやすいかな）」です。

Quality Gatesには以下の様な条件を設定できます。

コードカバレッジが50％以下になったらエラー。70％以下で警告

Quality GatesのステータスはERROR、WARN、OKの3つです。条件は複数設定可能なので、各プロジェクトにあった条件と閾値が使えます。

Quality Gatesの活用

まずは、最低限のコミットルールが守られているかを自動で確認できます。例えば、設定値の一つに「Public documented API (%)」というのがあるので、「APIドキュメントが10％すら書かれていないならNG」と設定すれば、ドキュメントの書き忘れを防げそうです。

notification

さらに、設定した閾値を超えたり下回ったりしたときに通知も飛ばせるので、品質基準値に「レビュー前にやっといてほしいこと」を設定できれば、レビューの効率性を高められそうです。

品質基準値のサンプルはMetric Definitionsを参考に、めぼしいものをピックアップして調べました。それプラス、以前、SonnarQubeを使って有名どころJavaフレームワークの品質を解析してみたので、そこで得た値も基準にしていきます。

Technical Dept Ratio

Technical Deptは、技術的負債を意味します。発音が「テクニカルデトゥー」なので、海外の方に「テクニカルデプト」って言っても通じないので注意が必要。SQALEという方法論を用いて計算しているそう。グレードはAからEまであります。

SonarQubeでの技術的負債の定義は、「課題すべてをFixしたときの成果」です。面白い定義内容ですね。よって、その割合（Technical Dept Ratio）は、「Fixコスト / 予想開発コスト * 100」になります。予想開発コストは以下の計算式。

予想開発コスト ＝ LOC x 30 minutes

各フレームワークをみると、すべて2％台なので、「3％未満」ぐらいの値が良さそうです。

Issue

課題の数です。Blocker > Critical > Major > Minor > Infoといったレベルがあります。内容にもよりますが、アプリ全体に影響が出るBlockerと、予期せぬ動きを引き起こしかねないCriticalは最低限潰しておきたいところ。

ちなみに、Majorは「複雑なメソッド」といった生産性に影響しそうなレベル。Minorはさらにマイナーなレベルの課題になります。

Coverage

テストカバレッジです。絶対にテストできなかったり（再現が難しいケース）、テストがすごくしにくかったりする場合（レアなCatch文とか）があるので、ちょうどいい度合いが必要になります。

自分の経験だとテストしやすいシステムだと90％いくけど、普通に開発しているだけなら70％いけばいいかなーぐらい。比較的新しいSpring Bootで71％なので、まずは60～70％を基準とするのがいいかもしれません。

また、「Coverage on new code」といった新しい（もしくは更新したコード）のカバレッジも品質基準値として設定できるので、既存と新規で使い分けてあげるといいかもしれません。

Duplicated lines (%)

重複した行の割合です。Javaの場合、少なくとも連続10行以上重複しているものをカウントしているみたいです。2％から8％の推移なので、これぐらいの値を基準にはじめてみるとよさそうです。

Complexity

functionの制御フローが分かれるたびに1増えるみたいなので（参考：Metrics – Complexity）、少ないほうがいいけどゼロにはならないでしょう（最小1）。ファイルが多ければ多い日ど値が増えるので、以下の平均値のトレンドを追うほうがよさそうです。

  • Complexity /class： クラスごとの平均
  • Complexity /file： ファイルごとの平均
  • Complexity /method： メソッドごとの平均

「Complexity /class」や「Complexity /file」だと値が大きくぶれている（Spring boot9.8、Play14.6）ので、メソッドでの分岐がちょうどよさそうです。どのフレームワークもメソッド内の複雑度を2以下に抑えているので、「Complexity /method： 2」を基準で考えるとよいかも。

Comments (%)

コメントの割合。以下の計算式になっています。

Comment lines / (Lines of code + Comment lines) * 100

10％から25％ぐらいを基準に考えると良さそうです。

Public documented API (%) = (Public API – Public undocumented API) / Public API * 100

というのもあるので、合わせて活用できそう。

まとめ

有名フレームワークの品質レベルを参考に基準値を考えたので、「はじめてのQuality Gates」であればこれではじめられそうです。あとは、やりながら「ちょっと品質基準が厳しいよね」とか、「これはもうちょっと高めに設定しよう」とか、チューニングしていくとよいかも。

Srpingプロジェクトで使っているQuality Gates設定や、dev.eclipse.orgのQuality Gates設定も参考になりそうなので、いろいろためしてみるといいかも。