コードを短くすると単体テストが楽になる、の検証編

さて、リファクリング前とリファクタリング後のソースコードがありますが、これがどの程度「安全」にコーディングができるのかを検証していきます。
検証するためには、何らかの定量的な手法が必要です。
# ちなみに「定性的な手法」は「ああ、コードが短くなったね」という感想が根拠になりますw

コードの複雑度を測定するのに、if 文などの制御文や使われている変数の数を勘定する方法がありますが、ここではもうちょっと簡単に、「変更できる箇所」を数え上げていきます。変更できる箇所というのは、コーディング時に間違えやすいところ/間違える可能性があるところで、≒テストが必要なところ、と言えます。

具体的には

・制御文でカウント
・比較文でカウント
・変数の宣言でカウント
・メソッド呼び出しでカウント
・メソッドの変数でカウント

のように、ちまちまと数えていきます。

で、数え上げたのがこれ。

▼リファクタリング前

▼リファクタリング後

赤い丸の箇所が、変更可能な箇所、いわゆる「自由度」になります。

数を勘定すると、
リファクタリング前は、59箇所
リファクタリング後は、36箇所

ざっと言うと、このコードだと 36/59 の差分で 40% 程度改善されている、といえます。

ちなみに、行数を更に短くした src.Select を使ったパターンを見てみると

▼過剰なリファクタリング?

この赤丸は31箇所あります。リファクタリング後のコードとほぼ同じですね。
一見、行数が短くて簡単になっているように思えますが、自由度としてはほぼ同じなので、どちらも使っても同じ不具合の発生率となる、と言えます。

こんな風に自由度をカウントしていくと、コードの複雑度が定量的に計算できるので、コードの複雑度を低くするようにコーディングをしていけば、不具合の発生率が下がって、作業時間が減り、よってプロジェクトの成功確率は上がる、という流れになるんですけどね。
このあたりは、感覚で勘定しても良いので、数万行のコードの中から複雑すぎるメソッドを抽出する、というようなツールができるといいかなぁとか。

カテゴリー: 開発, 設計 パーマリンク