VisualStudio - コードメトリクスで保守容易性指数を見る

Microsoft Visual Studio Professional 2012 通常版

ソースレビューをしているとパッと見で感覚的にココはまずそうというのが分かってくる。分かるというかピンとくる。で、よくよく見るとやっぱりまずい (だいたい)。パターンはだいたい一緒だったりする。

• 一つのメソッドが長い
• if 文のネストがひどい
• 変数名がやたら長い
• やたら linq が複雑でループしまくる
• 辞書とリストをこねくり回してる

パッと浮かぶのはそのあたりだけど他にも色々。レビューのたびに毎回指摘するのは流石にだるくなってきたので数値で出したいと思い立つ (遅い)。

いくつかツールを試して見たのだけど、手軽かつ分かりやすい Visual Studio のコードメトリクス計算で出力される保守容易性指数を使うことにした。

https://msdn.microsoft.com/ja-jp/library/bb385914(v=vs.110).aspx
保守容易性指数
コードの相対的な保守容易性を表す、0 ～ 100 のインデックス値を算出します。 値が大きいほど、保守容易性が優れていることを示します。 色分けしたコード評価を使用して、コード内の問題部分をすばやく識別することができます。 緑色の評価は 20 ～ 100 の範囲にあることを示し、コードの保守容易性が良好であることを示します。 黄色の評価は 10 ～ 19 の範囲にあることを示し、コードの保守容易性が中程度であることを示します。 赤の評価は 0 ～ 9 の範囲にあることを示し、保守容易性が低いことを示します。

実際にこの辺りの数値をどう算出しているかは ↓ のエントリにあったりするけど、なるほど分からん。

.NETでコード メトリックスを試してみる 第4回 - A certain engineer “COMPLEX”
保守容易性指数は、サイクロマティック複雑度とコード行とHalstead Volumeなる指標に基づいた値のようです。 - .NETでコード メトリックスを試してみる 第4回

気にせず結果だけ使うことにする。

実際に出力された数値とコードを見てみると MS の定義？より厳しくなるのだけど以下の感じでだいたい自分の感覚と一致する。

• 20 以下はアウト
• 21 〜 30 は改善が必要
• 31 〜 は良好

プロジェクトの開始時点にこの数値をクリアする縛りを入れておけば良かったなとちょっと後悔中。話が途中で上がってたけどなんとなく消えてしまった。ただ、現プロジェクトを解析してみると 20 以下は数えるほどなのでセーフ。でも一桁がちらほらあって・・・やっぱり中身を見るとアレなので辛い。そこがけっきょく全体のネックになってたりするからさらに辛い。

チームメンバーも数値を見て自信を持ったり凹んだりして、”ようやく” 読みやすいコードを書くように心がける空気が出てきたたから・・・まぁよしとする。結局、書いたコードが障害などの辛さで跳ね返って来るまで分からないのが辛み。散々言ってきたのになぁとは思うけどぐグッとこらえて前に。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)