前提

ソースコードレビューの頻度が低い環境でのコーディングが行われている。

ソースコードレビューで出た意見が、個人の主観に伴った偏った意見が多い。または、「うそだろ？」と口に出してしまいそうな、頓珍漢な回答しか返ってこない。

メソッド名や、変数名をやたらと「3文字※1」で略したがるコーダーがいる。または、メソッド名がパスカル、またはキャメルなのに、スネーク（_アンダースコア※2）が入ってくる。
このような現場で苦労しているエンジニア向け。

※1 おそらく、年配のエンジニアか、それをかっこいいと思っちゃっているアンテナの低い人。汎用機の時代は、プログラム名も変数名もなにもかも、文字制限があったためとにかく「略す」必要があった。現在は、わかりやすい英単語、またはローマ字で振る舞いを推察できるようにするのが一般的。
※2 コントローラーのイベントハンドラはMicrosoft的にあり得るかもしれない。phpのインターフェイス周りだったら全然あり。

■コードメトリクスとは？

VisualStudioに標準搭載されている、コード分析の結果を可視化したも。

[メニュー]→[分析]→[コードメトリクスを計算する]→[ソリューション用]
※プロジェクト用でも可

とすれば、ソリューション内のコードが機械的に分析される。
分析結果は階層型になっていて、フィールド、プロパティ、メソッドと確認可能。

■保守容易性指数とは？

そのコードがどれだけ保守しやすいかを分析した結果。ここは最低限、グリーンであることが大前提。20を下回ると色が変化する。緑から、黄色、黄色から赤と変化していく。ただ、この評価基準は非常に甘いというか、きちんとオブジェクト化が行われていれば、大体70～50前後になるはずだ。30を下回っているメソッドを見つけたら、リファクタリングをお勧めしたい。

■サクロマティック複雑度とは？

メソッド内がどれだけネストしているのかを分析した結果。テストコードを頻繁に書いているコーダーはわかると思うが、ifやcaseが頻繁出てくるとCaverage（※3）するのが大変。なぜなら、「その条件を通さないと」動作しないフローになるため、条件を整える必要があるからだ。

ifがネストしているとさらにテストは困難になる。「その条件を通すための条件」まで書いた上に、「その条件を通すための条件」と「その条件を通さないための条件」とテストケースが多様化し、ちょっとしたことで簡単に崩れてしまう砂山のようなコードが出来上がる。

それを避けるために、ネストの数をカウントしてくれるのがサイクロマティック複雑度。

※3 ソースが通った範囲。可視化するツールがあるので入れておいて損はない。

■継承の深さとは？

これは文字通り、継承の深さを分析した結果。もともと、基底となっている構造体やクラスは、いい意味での「あいまいさ」、抽象化が求められる。一回目の継承ではこのあいまいさは引き継がれているのは間違いないのだが、さらにもう一枚ラップをかけてしまうと、「あいまいさが保持されているか」がわからなくなってしまう。このラップをどんどん増やしていくと、基底の振る舞いが保持できなくなるので、継承の深さを可視化しているのだ。

※インターフェイスは別。そもそも中身がないので、どれだけ継承しようが問題ないはず。そもそもカウントされない。

■クラス結合とは？

そのメソッドが、どの程度外部のクラスに依存しているのかを分析した結果。

Microsoftの調査結果によると、上限値は9とのこと。なかなか厳しめの数字だ。コードのリファクタリングが進んでいれば、コードそのものが短くなる＆依存も減る、ということなのだろう。文中にもあるように、「優れたソフトウェア設計では、型とメソッドの凝集度が高く、結合度が低いことが求められます」とのこと。これは正直なところ、自身でも耳が痛かったりする。

自分の経験上、やたらと静的メソッドをひとまとめにしたクラスを作りたがる人が多いような気がする。Common的な、Constだけで埋め尽くされているようなクラスだ。それを可読化できるようオブジェクト的な、グループ分け（サブクラスなど）をしていくと、一つのメソッドからどうしても呼び出さざるを得ない外部クラスが頻出することになる。少々長めのメソッドになると、途端にスコアが低くなるのは重々承知しているのだが、この辺はプロジェクト次第ということもあるので、「何が原因でスコアが下がったのか」をきちんと理解しておかなければならない、と自分に言い聞かせていたりする。

■ソースコードの行とは？（2019からは実行可能コードの行も）
これも文字通り、ソースコード、実行可能コードの行を分析した結果。少ないに越したことはない。人の手が多く入っている個所ほど、バグが潜んでいるのは当然のことだ。

まとめ

どんなにたくさんのコードレビューを行っても、レビュアー次第で良い結果につながることもあるし、悪い結果につながることもある。残念ながら、インフルエンサーが必ずしも、自身にとって必ずしも「よい結果をもたらす」エンジニアではないのだ。なので、機械的な判断をするための手段と方法を理解しておくに越したことはない。うまくツールを使いこなして、より保守性の高いプログラムを書き続けていれば、自分の評価が上がるしメンテナンス時のバグの発生率を下げることになる。誰にとっても良い結果となるので、積極的に使用したいツールだ。