品質管理ツールSonarの記事
@ITにおかもとさんが品質管理ツールSonarの記事を書いておられたのでメモ。
【元ネタ】
コード探知機「Sonar」でプロジェクトの深海を探れ! (1/4) - @IT
メトリクスでソフトウェア品質を見える化する: プログラマの思索
Sonarはインストール出来ていたものの、使いこなせてなかったので、とても参考になる。
Sonarで一番知りたいメトリクスは複雑度だ。
複雑度と単体テストケース数の相関関係: プログラマの思索でも書いたけれど、複雑度と単体テストケース数は密接に絡んでいる。
ソフトウェア複雑度(McCabeのサイクロマチック数)
≒分岐網羅(C1)のテストケース数
≒単体テストケース数
という関係があるから、複雑度が大きいほど単体テストケース数が膨らむ。
たとえJUnitで単体テストを自動化していても、複雑度が大きすぎるプログラムはどこかにバグが潜んでいる。
IF文やFor文がたくさんネストしているプログラムは、それだけで簡単に複雑度は30以上は超える。
おそらくどんなシステムでも、複雑度が30を超えるプログラムは10個ぐらいはあるように思う。
特に本番稼働後、たくさんのパッチを当てる度に複雑度は増していく。
他の会社では、複雑度が15以上のプログラムはコードレビューを必須として、30を超えたら書き直すかどうか方針を下すという話を聞いたことがある。
個人的には、複雑度が30以上のプログラムは、リファクタリングして書き直した方が、その後の結合テストでも修正しやすいし、リリース後の運用保守でも機能追加しやすくなると思う。
こみいったプログラムの保守ほど嫌な作業はない。
プログラムに手を入れて変更するだけで、新たなバグを作ってしまう可能性が高いからだ。
SonarやStatSVNなどのメトリクス出力ツールを使って、いつでも開発者が自分たちのシステムの品質を見るようにすれば、自然に綺麗なプログラムを書こうという意識が生まれるだろう。
品質の見える化は開発者のプログラミング作法を自然に変えてくれるはずだ。
| 固定リンク
「ソフトウェア」カテゴリの記事
- Javaのenum型はシングルトンクラスみたいだ(2022.06.20)
- テスラが従来の自動車メーカーと異なるところは工場までソフトウェア化すること(2022.02.09)
- 「RubyやRailsは終わった」という記事のリンク(2022.01.09)
- 実践した後に勉強するのがエンジニアの本来の道(2022.01.09)
- DB Browser for SQLiteを使う(2021.12.21)
「ソフトウェア工学」カテゴリの記事
- メトリクス分析のコツは良いIssueを見つけること(2022.06.29)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
- 「大人の学びパターン・ランゲージ」の感想~知識と経験を行ったり来たりするタイミングを大切にする(2022.06.05)
- 「コーディングを支える技術」は良い本だ(2022.05.26)
- ソフトウェアテスト技法練習帳はテストケースの切り方に困っている人向けにおすすめの本だ(2022.05.14)
コメント