オープンソースのコード品質管理ツールである Sonar の最新バージョンは、Javaプロジェクトのアーキテクチャ制約ルールとカスタムなダッシュボードをサポートする。 SonarSourceチームが先月、この製品のバージョン2.4を リリースした。この新リリースには、４つの重要なフィーチャがある。
アーキテクチャ ルール: アーキテクチャ制約 ルール によって、開発者は、異なったパッケージにあるクラス間での参照を認めないパターン ベースのルールを定義することができる。パターンの例には、*.dao.* クラスから*.web.*へのアクセスを禁止したり、どのクラスからも java.util.Vector, java.util.Hashtable や java.util.Enumeration へのアクセスを禁止するものが含まれている。ソースコードがアーキテクチャ制約のセットに忠実に守れば、プロジェクトは、アーキテクチャ モデルを遵守することになる。このルールを使うには、Javaのバイトコード 分析が必要である。
カスタム ダッシュボード: Sonarのユーザは、マネージャ、開発者などのような会社の色々なステークホルダー向けにダッシュボードを作成し、カスタマイズ できる。カスタマイズするには、レイアウトを選び、ウィジェットを追加して、並べていけばよい。管理者は、全ユーザとダッシュボードを共有でき、デフォルトで表示するダッシュボードを選ぶことができる。Sonarツールの将来のリリースには、ダッシュボード用の新しいウィジェットが含まれ、そして、ユーザの役割に基づいて、プロジェクトのダッシュボードにアクセスできるようになる。
アップデート センター: 新しい アップデート センター は、プラグインのインストールとアップグレードに使うことができる。ユーザは、また既にインストールされているプラグインや互換性の検証に関する情報を入手したり、Sonarの新バージョンをチェックしたり、自動的に プラグイン 互換性マトリックスを管理できる。
Sonarの新バージョンは、アプリケーションのビルドとコード分析に Maven 3 をサポートしている。Sonarチームの Olivier Gaudin氏に新しいフィーチャについて聞いた。
InfoQ: アーキテクチャ ルールのフィーチャで、次の大きな機能強化は、どのようなものですか？
この最初のバージョンでは、アーキテクチャ ルールのエンジンは、「package Aのクラスは、 package Bのクラスから使われるべきではない」というような単純なルールを定義することができます。これの自然な進化として、DSLによって、複雑なルールを表現する機能を追加して、アーキテクチャ レイヤを定義し、次にレイヤAは、レイヤBとCからしか使うことができない、のようなルールを定義できるようになるわけです。Sonarにこのような機能を組み込むと、設計を監視するために外部ツールが必要になることは、ほとんどありません
InfoQ: Sonarプロジェクトの将来のロードマップを教えてください。
我々の主な目標は、プラットフォームを完全にいつでも使えるものにして、継続的なインスペクションのあらゆる側面をサポートし、開発チームに測定能力を提供し、その結果チームの技術的負債を管理できるようにすることです。我々は、このサポートを強化するために、3つの領域を次のターゲットにしています。
- 次のステップは、Sonar 2.5でルール違反がソースコードに発生した、ないし発生していた場合にダッシュボードの様々なビューで、それをより容易に追跡できるようになります。
- ある種のマニュアルのコードレビュー機能をプラットフォームに追加します。品質欠陥を追加、抑制、コメントしたり、議論できるようになります。
- SonarのEclipseプラグインにSonarの軽量バージョンを組込んで、SCMへのコミット前にコードレビューができるようになります。
その間、 SonarSourceの開発したパース技術を使って、新しい言語を追加し、既存のものに統合していきます、例えばCやCobolの新しいルールを追加します。