Codehausで2年間sonarを使って学んだtop10のこと

原文はここ

勉強になるのでまとめます。かなり意訳しています。

大事な部分を気にして小さくはじめよう。

sonarがデフォルトで使える静的分析にfindbugs,pmd,checkstyleがあります。これらのチェックルールは合計約800。しかし、pmdとcheckstyleには守るのが大変なマニアックなルールもあります。
マニアックなルールをちまちま守るより、findbugsで出る警告をチェックしたほうがいいでしょう。

ダッシュボードをチェックする

sonarを入れたはいいけど、使っているうちに分析結果をチェックしなくなることが多々あります。マネジャーはダッシュボードを定期的にチェックして、問題を確認し、開発者に連携しましょう。
結果、バグが発見できれば最高です。

ワーニングはできるだけゼロを目指そう

プロジェクトに大量のワーニングがあった場合、新しくワーニングが追加されても誰も見ません。なのでワーニングは常に０を目指しましょう。
ただ、ワーニングゼロポリシーは常に実行できることでもありません。もし、ちゃちゃっとワーニングを直せないんだったらワーニングゼロポリシーは無効にしてもいいでしょう。

ルールを理解して議論しよう

静的分析のワーニングはプログラムと問題解決方法を学ぶ良いチャンス。しかし、根本原因と影響を理解することは難しいかもしれません。
難しいワーニングを発生させる部分を分離し、正しい修正方法を探しましょう。スキルアップにつながるかもしれません。
ただし、なぜワーニングなのか分からないのに直すのはやめましょう。バグの原因です。

sonarは開発者のためにあります。

ワーニングを無効化することはチームにとってメリットはありません。sonar指針として「ツールは開発者のためにあるのであって、ツールのため開発者が働くのではない」です。
つまり、ツールの数字を改善するためにコードを書いたりしないでね。ということです。

sonarのデータベースを開発環境に突っ込まないで

Codehausでは最初、開発環境にsonarのデータベースを置いたそうです。結果、データベースのワーニングが出たりと色々面倒が発生しました。
また、ビルドに時間かかったり、自動化できなかったりと色々大変だったそうです。 sonarデータベースは専用のビルドマシン上に置くのが良いでしょう。

中央統合されたテストサーバを使おう

Codehausは分散統合されたテストサーバを使っていましたが、統合するために色々なツールやＤＢが必要だった用です。
大変なので、中央統合されているテストサーバが良いでしょう。

自動化しよう

ビルド、テスト、デプロイを完全に自動化することを目指そう。静的分析のもっとも重要な作業は頻繁に開発者に対してフィードバックすることです。

eclipse sonar プラグインを使おう

ビルドマシンのビルド結果が出るまで待つよりも、eclipse sonar プラグインを使って開発者側からsonarを起動しよう。
sonar プラグインを使えば、サーバと同じチェックをローカルで実施できる。このプラグインかなりいけてます。

決まった目標値は設定するな

コードカバレッジを90%以上とかコード重複を5%とかいう数値目標はやめよう。開発者はその数字を達成するためのコードを書き始めるから。
sonarのデータから得られた教訓を議論するほうが効果的です。

こんな感じです。つまり、sonarを使うなら

1.ciツールと連携するべし。
2.専用マシンを用意すべし。
3.ワーニングはなるだけ叩き潰すべし。
4.ローカルからsonarを使えるようにすべし。eclipesならsonar pluginを使うべし。
5.目標値のためにコードを書くべからず。

こんな感じ？
突っ込みウェルカムー。