はじめに
自分のもっているコードメトリクスについての考え・事例と参考情報を整理しておきます。
私の事例はC言語でコーディングされたソースコードに対する事例です。
原則
データ分析の注意点
アクションに結びつかないデータ分析をしないように注意する。
課題解決・問題解消につながらないデータ分析をしないように注意する。
今回テーマとしたコードメトリクスの活用についても、アクションに繋がることが重要である。
『データ指向のソフトウェア品質マネジメント―メトリクス分析による「事実にもとづく管理」の実践』
野中誠，小池利和，小室陸，「データ指向のソフトウェア品質マネジメント―メトリクス分析による「事実にもとづく管理」の実践」，日科技連出版社，2012
https://bookmeter.com/books/5474213
書籍に示されている「品質データ分析の作法」の中に、「作法7：アクションに結びつく分析を行う」がある。
####『日本企業がデータドリブン企業になれない本当の理由とその解決方法』
河本薫，「日本企業がデータドリブン企業になれない本当の理由とその解決方法」，ソフトウェア品質シンポジウム2020，2020
https://www.juse.jp/sqip/symposium/2020/timetable/files/kichou-kouen_happyou.pdf
河本薫さんの講演資料の中に以下の言葉が出てくる。
データ分析のゴールは、課題を解決し、問題を解消することである。
私の考え・事例
メトリクスの検討
ポイント：まずは、データを分析するのではなく、バグを分析する
以下の2つのアプローチのうち、B)のアプローチのほうがうまくいく可能性がある。
- A) 複数のメトリクスから、バグ件数との関係の強いメトリクスを選択する
- B) バグの原因を特定し、その原因を事前に検知することを可能とするメトリクスを検討する
B)のアプローチの場合、具体的のどのようなバグにつながるかの事例が紐づくため、開発者が理解・納得をしやすい。
メトリクスを見て危ないと認識できなければ、アクションは起こされない。
B)のアプローチは、”バグ”ではなく”バグの原因”を検知するためのメトリクスを検討するということである。
このバグの原因の表現方法の一つが、「コードの不吉な臭い（Code smell）」である。
メトリクスを検討するときに、まずは自分の組織で発生していた「コードの不吉な臭い（Code smell）」を特定することからはじめてみるのもよいかもしれない。
リファクタリングでの活用
ポイント：リファクタリングする時間を確保しておく
リファクタリングで、メトリクスを活用するときには、有効なメトリクスを選択するという行為はそれほど重要ではないと考えている。
開発現場で簡単に利用可能なツールで、手間をかけず計測可能なメトリクスであればよいと考えている。
私のチームでは、昔から品質に影響があるといわれており、ツールで計測が可能な以下のようなメトリクスを確認し、リファクタリングの要否判断をしていた。これらのメトリクスで、十分にリファクタリングのきっかけが得られた。
- コード行数
- サイクロマティック複雑度（経路複雑度）
- 最大ネスティング数
「メトリクスの選択」より重要なのは、「リファクタリングの時間の確保」であると考えている。
ここ直したほうが良さそうだなぁと思っても、直す期間がないと、結局何もアクションできない。
開発期間中に、メトリクスを計測・分析した後、リファクタリングをするフェーズを用意しているかがポイントである。
テストでの活用
ポイント：コードの複雑さに対するテストの過不足を確認する
私のチームで、関数単体テストにおいて、サイクロマティック複雑度とテスト項目数を比べ、テスト設計の検証をする活動を実施したことがある。
具体的には、「複雑度が高いのにテスト項目数が少ない」「複雑度が低いのにテスト項目数が多い」という関数について、以下を確認していた。
- テスト設計に見直すべき点がないか？
- テスト設計者はテスト設計方針を理解しているか？
この活動は、テスト設計に関する問題を検出することに役立った。メトリクスによる検証とテスト設計のレビューを組み合わせることは効率的かつ効果的であると感じた。メトリクスによる検証により、レビュー対象を問題のありそうな箇所に絞り込むことができたり、レビューで見逃した問題を検出することが可能となると考えている。
コードメトリクスとテストに関するメトリクスを組み合わせることについては、以下の記事・コメントでも言及がある。
参考情報
新たなメトリクス
私は活用したことないが、活用できたら面白そうだなぁと思ったコードメトリクスをメモしておく。
変更の回数／変更した人数
保守容易性指数
インパクトスケール
影響波及パス
バグが良く発生する箇所Top3
JaSST'21 Tokaiで高橋寿一氏が自身の経験から「バグが良く発生する箇所Top3」を提示してくださっていた。
高橋寿一，「もうちょっと楽に単体テストしませんか？」，JaSST'21 Tokai，2021
http://www.jasst.jp/symposium/jasst21tokai/details.html#S2
http://jasst.jp/symposium/jasst21tokai/pdf/S2.pdf
Top1:よく変更されるファイル
Top2:長いファイル
Top3:複雑度が高い
関連記事