細かく書きたいけど、とりあえずメモだけ。
- ステップ数が増ている
- なんらかの開発が行なわれている
- ステップ数が減っている
- リファクタリングが行なわれている?
- 単に仕様落ちしたコードが削除された可能性もある
- テストカバレッジが下がる
- テストが書かれていない ... ステップ数が増えている場合
- テストが減っている ... ステップ数が変わらない場合
- FindBugs 、 PMD 、 Android Lint の警告数が増えている
- 品質の低下、レビューが正しく行なわれていない
- CPD 警告数が増えている
- 品質の低下、レビューが正しく行なわれていない
- そろそろリファクタリングしたほうがいい
- Checkstyle 警告数が増えている
- 品質の低下、レビューが正しく行なわれていない
Jenkins で継続的にビルドしたり、テストを行なうのは言うまでもなく大切だけど、こういった静的解析の数値をグラフ化していくのも相当重要なのでは無いかなと思う。
コードが読めないマネジャーや企画、営業の人にもソフトウェアの品質を "ある程度" 伝えることが出来るのでは無いかな。
昔、ウォーターフォール的な開発をしていたころは、 QA は極めて工学的な理論に乗っ取ってやっていたように思えるんだけど (それが意図通りに作用していたかはともかく) 、いまどきのスタートアップとかがやるアジャイル開発においては、ソフトウェア信頼性工学ってそこまで重要視されてないように思う。
リリースのイテレーションが早いから、そういうこと考えなくてもリリースして壊れたら直せばいいみたいなのはあるんだろうけど、まあでもリリースする前に品質の低下が分かるに越したことはないし、こういった分野の話がもっと活発になると良いのになあ。
追記 (5/6 0:25)
フリーで使える静的解析ツールはとにかく使うようにしたほうがいいし、Jenkins で描画できるグラフは全部描画したほうが良いと思う。
- まずデータが無いと駄目
- とにかくデータありき
とにかくデータが無いと始まらない。これは録画に限らずどんなことにも言えると思っている。データは蓄積してみないと利用方法は分からないし、グラフは描画し続けないと変化は分からない。
Jenkins を使っているけど静的解析のグラフ化に "いまいち効果が分からない" とか "何が便利なんだろう" と思っている人も、とりあえず静的解析してみるというのは良いと思う。
すぐに利用方法が思い付いたり、グラフの効果が分かるわけでは無いけど、 3 ヶ月くらい記録しつづければデータから見えてくるものがあるんじゃないかと思う。
追記 (5/7 17:51)
Jenkins で静的解析の結果を可視化すると "非エンジニアでも品質がある程度見えて良いよね" とか "潜在バグがありそうなコードを直したくなるので良いよね" くらいの気持ちで書いた *1 んですが、どうやら静的解析の結果を個人やチームの評価にされてしまう危惧をしている人がいるようです。
個人的には、マネジャーが「なぜ数値が悪くなったんだ」と言ってくるのは至極真っ当なことで、開発者がテストを書かなかったり、作法に従ってコーディング出来ていないのが悪い。速やかにテストを追加したりコードを修正すればよいのです。
まあ、皆さんが気にしているのはそういうことでは無くて、静的解析の結果を "個人やチームの能力評価" に繋げられることを危惧しているのだと思う。
この辺って結局、 "ステップ数でプログラマの生産能力を評価する" みたいなのに通じてしまうんだろうなあ。プログラマの能力は定量的に測れないので諦めてくださいと言うしかないけど、マネジメント側としては数値化されているほうが分かりやすくて良いのでしょう。さすがに 2013 年にもなるのだし、そういうマネジメントは行なれてないと信じたい。
ただ、数値が悪くなることはマネジャーに説明するまでも無く確実に悪いことなので、プロセスとして "静的解析の警告を減らす・無くす" ようにしていけば良いと思う。例えば、コードレビューの際に一定の警告数を上まわると自動的にリジェクトするとか、警告が増えてきたら開発を止めてリファクタリングをするとか。
*1:ゴミが可視化されると掃除したくなる
