放課後プログラミング

調べたことや考えたことなどを忘れないために書きます。

SonarQubeの上手な使い方

SonarQubeとは、コードの品質を可視化し、継続的に監視することで、抱えている技術的負債を制御可能にするためのプラットフォームのこと。*1
技術的負債を抑えて保守性を高めることは、チームの生産性を高いレベルに維持することに大きく寄与するので、継続的に内製開発をする場合は是非とも検討したいツールに見える。

そんなSonarQubeについて半年くらい前に会社で紹介したところ、部署全体で導入することになった。

で、半年くらい経ったが、現状SonarQubeは(Jenkinsと併せて使うことで)ある程度は技術的負債の発生を抑止することに役立っている。
しかし、導入してJenkinsビルド時に一緒に解析するように設定しただけでは、技術的負債を制御可能にはならない。
それを可能にするためにはどのようにSonarQubeを使えばいいか、僕が実践している方法を書く。
したがって、この投稿は導入してみたけどイマイチだなって思った人向けだ。もしかしたら使い方を変えれば認識も変わるかもしれない。

機械的に判断できる箇所しか検知できないことを意識する

SonarQubeを導入すれば保守性については万事OKとなるわけではない。それどころか、現状僕がいるチームではSonarQubeの保守性の維持に対する貢献度は5%に満たないだろう*2
保守性とはそもそも保守する人間に依存した性能だ。保守者が猿であれば誰も保守性の高いコードは書けない。したがって保守者の間でどこまでが共通認識となっているかを把握し、その共通認識となっている知識を前提として読んだ際に最大限理解しやすく書くことで、保守性を最大化できる*3
しかしSonarQubeにはそのような共通認識を細かく記述する機能はないし*4、それができたとしても、その共通認識から人間であれば殆どが理解しうる記述かどうかを判別する知性もない。あるのは一般的に言われる「AはBのように書くべき」という極めて単純なルールの違反を機械的に検知する機能だけだ。当たり前のことだが、それを意識することで、「これは機械に任せよう」「これは人間で対応しよう」という境界が見えやすくなり、このツールを有効に使うことができるようになる。

SonarQubeを有効利用する手順

半年ほどSonarQubeを使ってそれなりに役立っている利用方法を紹介する。

手順1 : QualityGateを設定し、BuildBreakerプラグインを導入する

  1. QualityGateを設定し、BuildBreakerプラグインを導入することで、Jenikinsでビルドする際にコードの品質が閾値を跨ぐとビルドをFAILUREにさせられる。
  2. この際にBlocker,Critical,MajorのIssueが0以上であればFAILするようにしておく。閾値を0より大きくすると今回は仕方ないから増やそうみたいになって良くないので、徹底する。
  3. とにかくIssueの扱い方でSonarQubeを有意義に使えるかどうかが決まると言っても過言じゃない。
  4. テストカバレッジや重複コードの閾値などはお好みで*5

手順2 : プロダクト専用のQualityProfileを作成する

  1. デフォルトのQualityProfileをコピーしたもので良い。プロダクト専用にしておくのが重要。

手順3 : Jenkinsでビルドする

  1. JenkinsのビルドとともにSonarQubeの静的解析が走り、例えばMajor Issueが100個出て失敗したりする。こっからの対応方法が重要!
  2. この中には「うちのプロダクトではこれは別にOKだと思うけどなあ」というものが結構ある。それを一つ一つ精査し、その検知が不要であればQualityProfileの編集画面でそのルールをMinorやInfoに格下げする。
  3. あるいは、例えばロガーの命名はデフォルトでLOG(?:GER)しか認められていないが、単一クラスでも複数種類のロガーを使い分けていてFOO_LOGGERBAR_LOGGERとしたい場合などは、ルールの定義を書き換える。
  4. もちろんルールが妥当であれば、コードの方を直す。

このように運用していると、だんだんとQualityProfileがそのプロダクトに最適化されていき、余計なIssueでビルドが失敗せず、尚且つ監視したいルールは違反した時に検知できる、という状態になる。
このようにプロダクトに合ったルールに書き換えていくことで、SonarQubeは本来の力を発揮できるようになる。

忘れてはならないのは、SonarQubeは保守性のほんの僅かな部分でしか効果を発揮できないということ。日頃からチーム内で密にコミュニケーションを取り、共通認識のレベルを高めておくことのほうが断然、保守性を高めることには効果的である。
それではみんな仲良くソフトウェア開発を楽しみましょう。

*1:SonarQube

*2:それ以外はコードレビューやペアプロによるスキル(プログラミングの技術に加え、特定ドメインにおける知識等も含む、これらのチーム内での共通認識のレベルをここではスキルと呼んでいる)の向上によって保守性を維持できる。

*3:そのため、自分が読みやすいからといってそれが保守性が高い状態とは言い切れない。意味不明なコードや文章を書いてしまう人はこれを認識し損ねているか、共通認識を見誤っているかのどちらかの可能性が高い。そのコードや文章を読む人が意味不明と思った時点で、それは良くない。僕が書いたコードや文章も、対象としている人が読んで意味不明と思ったら、それはうまく書けてないということ。

*4:あったとしてもそれを入力することは非常に大変であることが『人工知能は人間を超えるか (角川EPUB選書)』に書かれている

*5:参考:http://qiita.com/naiad/items/163e0a47b62df89cdfcf