日曜日に腹痛で病院にいったら、入院になり、翌日盲腸と診断されてそのまま手術して先日退院してきました。
まだ、おなかの傷が痛むので今週は養生しようと思うので手を動かすのではなくツールを使ってみた！って感じの記事を書いてみたいと思います。
Visual Studio 2019 にはコードメトリクスの分析機能があります。
こんな感じで分析メニューからいけます。
丁度、先日リリースされた Covid-19 Radar のプロジェクトが手元にあったので分析にかけてみました。
実行すると以下のような結果が表示されます。
このウィンドウ上部にあるエクセル風のアイコンをクリックするとみんな大好き Excel で結果が開かれます。あとは好きなようにソートしたりフィルターしたりできます。
このプロジェクトの全体のコードを見たわけではないですが、メソッドだけに絞ってサイクロマティック複雑度でソートしたら以下のような雰囲気になりました。
これはサーバーサイドのコードですがメソッド単位でのサイクロマティック複雑度の最大値が 13 というのは、私が昔仕事などでコードの分析する際に提出されてきたコードでは出会ったことがありませんでした。
50 超えなんて珍しくもなく数百になるものも中にはあったりすることもあるので、このコードはサイクロマティック複雑度的にはかなり綺麗に整理されたコードなんだなぁというのがわかります。
クライアント側のコードのサイクロマティック複雑度も同じようにメソッドのみに絞り込んで表示してみたら最大のもので 18 でした。
Exposure Notification の API をスマホで有効化するという処理と通知などの処理が主で複雑な Bluetooth LE の電波強度から接触したかどうかという処理がアプリ内に不要なので、割とさっくりと作られているように感じます。
実際に数コミットくらいは私の名前もコミットログにあるのですが、触ってみるときにメソッドが短いので読みやすいコードだなぁと思いました。なので、 C# をやったことがある人には巨大なメソッドがないメソッド単位で見た限りだと綺麗に分割されていそうなプロジェクトを読みたいというのであれば Covid-19 Radar のコードの Azure Functions と Xamarin のコードをクローンしてみてみてみるというのは、もしかしたらアリなのではと思いました。
サイクロマティック複雑度
ここまで散々言ってきたサイクロマティック複雑度ですが、循環的複雑度という名前でも使われていて（私のまわりはサイクロマティック複雑度でした、まぁ英語をそのままカタカナにするか漢字にするかの違いです）
端的に言うとソースコード内の処理の経路の数。つまりこのメソッドの全てのパターンをテストしようとすると最低でも、この数字と同じ数だけのテストケースを実施しないと出来ないというものです。
個人的な所感では、これが 20 を超えてくると危険です。まぁでもエンタープライズアプリケーション開発の現場では数百とかいうのがざらにいるので感覚麻痺しちゃうけど麻痺したら危険信号なので気を付けましょう。
こういったソースコードの各種メトリクスは、CI/CD パイプラインで継続的に計測しておくとソースコードを俯瞰する立場の人からしたらありがたいです。
有名どころだと SonarQube を使ってるところが多いんじゃないかと思います。Qiita にもいくつか記事があるので気になったら見てみるといいと思います。
昨日に比べてなんか複雑度の多いコードがバカみたいに増えてるんだけど！？っていうのに気づいたときに対処できるので個人的には好きです。
まとめ
Covid-19 Radar のコードはメソッド単位（クラス間の依存関係とかは今回は見てないのでそこは知らない）の複雑度で見ると凄く整理されてメソッド分割されているように見えました。実際に私も個人的にコードを見たり少しコミットするために見たときには「何だこのメソッド！？複雑でよくわからないから近づかんとこ…」というのはありませんでした。
サーバーサイドのほうについてはユニットテストもあってユニットテストのコードカバレッジを見ると 70% もユニットテストでカバーしているので、本当にお手本みたいな書き方がされているので興味のある人は見てみるといいと思います。
ではでは。