品質管理ツールSonarの記事
@ITにおかもとさんが品質管理ツールSonarの記事を書いておられたのでメモ。
【元ネタ】
コード探知機「Sonar」でプロジェクトの深海を探れ! (1/4) - @IT
メトリクスでソフトウェア品質を見える化する: プログラマの思索
Sonarはインストール出来ていたものの、使いこなせてなかったので、とても参考になる。
Sonarで一番知りたいメトリクスは複雑度だ。
複雑度と単体テストケース数の相関関係: プログラマの思索でも書いたけれど、複雑度と単体テストケース数は密接に絡んでいる。
ソフトウェア複雑度(McCabeのサイクロマチック数)
≒分岐網羅(C1)のテストケース数
≒単体テストケース数
という関係があるから、複雑度が大きいほど単体テストケース数が膨らむ。
たとえJUnitで単体テストを自動化していても、複雑度が大きすぎるプログラムはどこかにバグが潜んでいる。
IF文やFor文がたくさんネストしているプログラムは、それだけで簡単に複雑度は30以上は超える。
おそらくどんなシステムでも、複雑度が30を超えるプログラムは10個ぐらいはあるように思う。
特に本番稼働後、たくさんのパッチを当てる度に複雑度は増していく。
他の会社では、複雑度が15以上のプログラムはコードレビューを必須として、30を超えたら書き直すかどうか方針を下すという話を聞いたことがある。
個人的には、複雑度が30以上のプログラムは、リファクタリングして書き直した方が、その後の結合テストでも修正しやすいし、リリース後の運用保守でも機能追加しやすくなると思う。
こみいったプログラムの保守ほど嫌な作業はない。
プログラムに手を入れて変更するだけで、新たなバグを作ってしまう可能性が高いからだ。
SonarやStatSVNなどのメトリクス出力ツールを使って、いつでも開発者が自分たちのシステムの品質を見るようにすれば、自然に綺麗なプログラムを書こうという意識が生まれるだろう。
品質の見える化は開発者のプログラミング作法を自然に変えてくれるはずだ。
| 固定リンク
「ソフトウェア」カテゴリの記事
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- Javaのモジュールシステムの考え方をまとめてみた(2022.10.21)
- Javaのenum型はシングルトンクラスみたいだ(2022.06.20)
- テスラが従来の自動車メーカーと異なるところは工場までソフトウェア化すること(2022.02.09)
- 「RubyやRailsは終わった」という記事のリンク(2022.01.09)
「ソフトウェア工学」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
コメント