どうやってソフトウェアのまずさを数値化するかを調べてみる

このエントリーをはてなブックマークに追加
開発エンジニアのsugimotoです。
弊社サービスのMARKETING PLATFORMの開発を担当してます。
近頃はソースコードのまずさによりメンテナンスコストの増加やメンテナンスによる新たなバグの発生で悩むことが多かったので、今回はこのまずさをどう数値化したものかを調べてブログに書いてみます。

○技術的負債
ソースコードのまずさを負債と捉えて数値化できるのではと考え技術的負債について調べてみました。技術的負債のちゃんとした内容はWikipediaとかInfoQとかの記事を見てもらうのが良いので、ここでは理解した内容を簡単にまとめてみます。

・負債
まず負債って何?ということなんですが、お金と同様に借金です。ソフトウェアの場合、借金に当たるのが良い設計(あるべき姿)に対してどれだけ妥協した設計で作ったかを表します。式で表すと

  負債 = 良い設計で作ったもののコスト - 妥協した設計で作ったもののコスト

になります(下図参照)。



当然負債なので利子の支払いや負債の返済が必要です。

・利子
利子はメンテナンス時に掛かるコストの差分です。基本的に良い設計で作った方がかかるコストは少ないので、妥協して作ったものをメンテナンスすることで余計に掛かるコストが利子になるわけです。これを式で表すと

  利子 = 妥協した設計で作ったものをメンテナンスするコスト - 良い設計で作ったものをメンテナンスするコスト

で表現できます(下図参照)。



このコストは1回だけでなく、メンテナンスする度に掛かりますし、その度に大きさは違います。

・負債の返済
負債の返済なんですが、これはリファクタリングによって良い設計に基づいたものに作り変えるコストになります。部分的にでもリファクタリングすることによって借金を返済することは可能です。ここで、負債=返済額なのかという疑問が浮かびますが、実際には違うはずです。つまり借金した分だけコストを掛ければ完済できるわけではないんです。



これは、真っ直ぐあるべき姿に進んでいれば一番コストが少ないわけですが、多少なりとも遠回りしているのでその分が掛かるためです。
ただ、実際のお金と違い借金を返済する義務がありません。返済しないとメンテナンスの度に利子を払うだけなわけです。なので理屈上は、

  良い設計で作ったもののコスト + 良い設計で作ったものをメンテナンスするコストの総和 > 妥協した設計で作ったもののコスト + 妥協した設計で作ったものをメンテナンスするコストの総和 (+ 良い設計のものに作り変えるコスト)

であるならば、別に妥協した設計で作ってもいいという判断ができるわけです。
ただこれはあくまで開発コストだけのお話なので、早く出すことのビジネス上のメリットやパフォーマンスに掛かるコストが入ってないので実際はさらに複雑です。

で、理屈はわかったのですが、実際にこんなの出してたら面倒臭すぎてやっていけないというのが正直な感想です。特に既に抱えている負債を数値化するのが非常に大変。ということでいったん技術的負債をソフトウェアのまずさとして数値化するのを却下しました。

(技術的負債のいろいろな意見はInfoQの記事で見てみると良いと思います)

○ソフトウェアの定量的手法
次に検討したのがソフトウェア工学での定量的手法に頼ってみる案です。Wikipediaの「ソフトウェア測定法」によると次のようなものがあるらしいです。

・成長オーダー(アルゴリズム解析、O記法など参照)
・ソースコードの行数
・循環的複雑度
・ファンクションポイント法
・ソースコードの行当たりのバグ数
・コード網羅率
・顧客要求仕様の行数
・クラスおよびインタフェースの個数
・Robert Cecil Martin のソフトウェアパッケージ測定法
・凝集度
・結合度

この中で参考になりそうでコントロールできそうなものが、ソースコードの行数(メソッドの行数の方が良い)、循環的複雑度、コード網羅率、凝集度、結合度の5個。この中でツールを使って取得できるものがソースコードの行数、循環的複雑度、コード網羅率の3個。1個1個がどのようにまずさを表すかを考えてみます。

・ソースコードの行数(メソッドの行数)
あまりに長いメソッドは可読性を悪くなるために、メンテナンスもしづらくなります。行数が大きければ大きいほどまずいコードであると考えて良さそうです。

・循環的複雑度
プログラムの複雑さを数値化するためのものです。複雑であればあるほどメンテナンスコストも上がりますしバグの温床になりやすいです。この値が大きければ大きいほどまずいコードと考えて良さそうです。

・コード網羅率
自動テストのカバー率。自動テストがない場合、その分は手動テストでしなければならないし、反復して実行するのも容易ではないため、コストや品質の両面で良くありません。ですので、カバー率が低い場合はまずいコードと考えて良さそうです。

ということで、今後これら3個の指標を用いて担当ソフトウェアのまずさを数値化してみようと思います。本当は結合度や凝集度も入れたいところですが今のところは難しそうなので。機会があったらやってみた結果をまたブログで報告します。
次の記事
« Prev Post
前の記事
Next Post »
Related Posts Plugin for WordPress, Blogger...