Sonarはオープンソースのソフトウェア品質管理プラットフォームだ。次のようなソフトウェア品質メトリクスにフォーカスしたWebダッシュボードを開発者やステークホルダーに提供する。
- ユニットテストの成功とコードカバレッジ
- ソースコードの違反解析 (FindBugsに似ている)
- CC、RFCやLCOM4といったソースコードメトリクス
- パッケージサイクル (JDependに似ている)
- コードの重複行検出
- コード行数、パッケージ数、クラス数、メソッド数などの計測
- 長期の品質トレンドを表示する履歴チャートやグラフ
コアアプリケーションはデフォルトでJava言語をサポートしている。追加プラグイン (いくつかは商用製品) を使うことで、C、C#、Flex、Natural、PHP、PL/SQL、Cobol、Visual Basic 6のメトリクスを分析できる。分析はプロジェクトのビルドフェーズで実行される。Sonarはビルドサーバ (たとえばJenkins/Hudson) と簡単に統合でき、メトリクスを頻繁に更新できる。SonarSource (Sonarのバックにいる会社) によると、開発チームは時間の経過とともにアプリケーションの品質状況をモニターできるので、このプラクティスは基本的に継続的インスペクション(Continuous Inspection)形式になるそうだ。
Sonar 3.0の最近のリリースでは、既存のオープンソース版にあったコミュニティサポートに加えて、商用サポートを提供している。Developer Cockpitという形で提供される興味深い新機能もある。これは開発者がアプリケーション品質に対する自分の貢献度をフォロー、マネジメントできるようにする商用プラグインだ。通常、Sonarはだれが書いたか関係なくソースコードを集約した結果を提供する。このプラグインはプロジェクトのソースコード管理システムのリポジトリにあるユーザアカウントと組み合わせて、すべてのSonar情報をパーソナライズ化する。これにより、自分のコミットがコード品質にどんな影響を与えているか、開発者個人が確認できるようになる。
InfoQはOlivier Gaudin氏 (SonarSourceのCEO/共同創業者) にコンタクトして、Sonarのこれまでとこれからについて話を聞いた。
InfoQ: 3.0のリリースで、SonarにはEnterprise版とProfessional版が登場しましたね。それぞれのターゲットはどこですか？ オープンソース版はこれからもフリーで利用できるのですか？
もちろん、Sonarのオープンソース版はこれからもフリーで利用できます。これはSonarのバックにあるSonarSourceのDNAの一部です。SonarSourceにおける私たちの一番の目標は、あらゆる開発チームがコード品質管理のためのツールを利用できるようにすることです。私たちはこの数年で、内部品質を管理することが、ほとんどのチームの開発プロセスに組込まれると信じています。したがって、内部品質管理ツールの市場は大きいと同時に、オープンソース製品を利用するカルチャーの強い市場だと考えています。
そうは言っても、顧客の多くは大企業で、私たちのソリューションを大規模な開発チームで使っています。彼らはコミュニティからだけでなく、ベンダーからのサポートを期待しています。オンサイトでのサポートを望んでいる会社もあります。これがProfessional版とEnterprise版を用意した理由です。どちらもオープンソースプラットフォームであるSonarをもとにしています。
InfoQ: Sonarの強みのひとつに、コア機能を補完する複数の外部プラグインが利用できることがありますね。しかしプラグインAPIは過去のバージョンから大きく変更されているようです。プラグインAPIを安定化させ、もっとよい後方（あるいは前方も）互換性を実現する取り組みはありますか？
私に言わせると、Sonar APIが大幅に変更されたと言うのはあまりフェアではありません。私たちがSonarの最初のEnterprise版 (Sonar 1.5) をリリースしたのは3年以上前で、そこで巨大なAPIを提供しました。このAPIを設計するとき、私たちはいくつかのミスをしました。後になって、それがAPIの将来の発展を困難にするとわかりました。そこで2年ほど前、私たちは後方互換性を保たずにAPIの一部を書き直すことに決めました。すべてのプラグインを新しいAPIに移行することで、プラグインのForgeに打撃を与えました。IsotrolプラグインはForgeの一部ではありませんでした。さらにIsotrolは、Sonarプラグインはもはや優先事項ではないと私たちに知らせてきました。これにより彼らと会話するのが難しくなりました。私の知るかぎり、API問題のためにリタイアしたプラグインはこれだけです。それからはずっと後方互換性を確保し、よい仕事をしてきたと思っています。それはそうと、これとよく似た新しいプラグインがコミュニティによって作られています。それはTotal Qualityというものです。
InfoQ: 初期のSonarはコード分析に既存のJavaツール (PMD、JavaNCSS、Checkstyleなど) を使っていましたよね。しかし最近は、自身のコード分析 (すなわち Squid) を持つようになり、機能の一部を置き換えていますね。カスタムのワークフローをもつ人たちやSonarを使いたくない人たち向けに、こうした機能をスタンドアローンの分析ツールとして公開する予定はありますか？
ええ、自分たちの目標を実現するには、既存のツールを統合するだけでは不十分だと感じていました。そこでSquidという独自のパース技術の開発をスタートしました。Squidはライブラリとして設計されており、Sonarとは独立して利用できます。私たちがそう設計したのは、Sonar以外でもすぐれたアナライザのニーズがあるかもしれないと思ったためです。
InfoQ: Google testability explorerはすぐれたアイデアですが、開発が止まっているようです。その機能をSonarに統合する計画はありますか？
実のところ、すでにtestability explorerを統合するSonarプラグインがあるのですが、こちらも止まっています。私たちにとって、これはcrap4j、Keith Braithwaite氏の複雑さの分布とTDDの関係に関する考察、デメテルの法則、ボブおじさんのO.O. Design Quality Metrics (PDFへのリンク)など同じような題材です。私たちは常に、実験的なツール、コンセプト、メトリクス（おそらくLCOM4を除く）を実装するのではなく、本当に実用的な情報を提供する堅牢なプラットフォームにするというアプローチをとっています。提供される情報が実用的な情報だと確信できたときに、こうしたツール、コンセプト、メトリクスを統合していきます。
InfoQ: 少なくともJavaに関して、SonarはMavenに密接に統合されていますね。ほかのビルドシステム (たとえば AntやGradle) はMavenと同じレベルでサポートされますか？
この質問に異を唱えることができてうれしいです! 確かに、Sonarは当初、Mavenと密に結合していました。しかし1年以上かけて、そうした結合を取り除き、Mavenは今やAnt、Gradle、Sonar runner (Javaバッチ) と同様、Sonarの「ただの」ブートストラッパーです。これらすべてで同じ機能が使えます。これはSonar-Eclipseプラグインを開発するための要件でもありました。このプラグインはSonarプラットフォームの採用をさらに拡大するものです。
Sonarについて詳しくは、リファレンスや追加プラグインを参照してほしい。一番重要なのは、人気のあるオープンソースプロジェクトを分析するライブデモだ。製品比較のページには、商用サポートオプションを含む詳細な価格が載っている。