技術的負債の 「見える化」
どのようなソフトウェアにも設計上のミスはあります。設計時点ではサービスの発展性や日々変わりゆく要件を完全に予測することはできないからです。ある時点で正しい設計も,
mixiでは技術的負債は長らく,
コンポーネント内の負債指数
コンポーネント内部の負債の評価には,
クラスの単一責務の違反指数
先ほど,
具体的には,svn blame
SRP=R+U+((L/
100)-5) - R:修正リビジョンのユニーク数
- U:修正ユーザのユニーク数
- L:モジュールのライン数
この値が大きければ大きいほど単一の
この指標を各コンポーネント内のコードに適用し,
バージョン管理システムを利用していれば簡単なスクリプトで計算できるので,
関数の循環的複雑度
次に,
まず単一の関数の循環的複雑度
M=E-N+2P
- E:グラフのエッジ
(関数内の処理のブロックをつなぐ線) 数 - N:グラフのノード
(関数内の処理のブロック) 数 - P:連結されたグラフの数
たとえば次のような関数があるとします。
do_one();
if( is_foo() ) {
do_var();
} else {
do_hoge();
}
do_moga();
この関数は図2のようなグラフ構造を描きます。ここから,
そこからあるコンポーネント全体の循環的複雑度
CC = sum map{ $_ -20 }
grep {$_ > 20 }
@method_complexities;
20
は,@method_
は,
コンポーネント内の負債指数の計算
単一責務の違反指数や関数の循環的複雑性の高さは,
- P=SRP×CC+(SRP+CC)
このスコアは,