住友電工の論文で見かけました。
統計的品質管理によるソフトウェアの品質改善
http://www.sei.co.jp/tr/staticFile/59/rakcat&DESTINATION=TLVL03&HAKKO_NO=174&TECHNICAL_CD=299.htm
当社の基幹系ソフトウェアでは、プログラム中のIF 文の数がプログラムに含まれる欠陥数と相関があることが回帰分析により得られた
話の筋としては、テストの工数にキャップをかけるために、実装結果から潜在的な欠陥の数を見積もることが必要→たまたまSEIではIFの数と摘出される欠陥の個数に相関があるのでそれを利用、ということのようです。
ifやswitchによる分岐がバグの温床になるのは皆さん体験済みだと思います。
無駄な分岐はできるだけ作りこまないようにしているベテランさんも多いと思います。
さて、例えば巨大switchを避けて、構造体によるテーブルで処理するように実装したりすると、
すべての場合をテストできないから、レビュー通らないよ、それ
というわけの分からない話が出てくることがあります。
if/switchの場合は、if～elseの全パターン、あるいはcaseの個数だけテストすれば完全なのに、テーブル処理の場合は、すべての入力パターンをテストしなければならないとい主張です。
そうやって、知らない人たちの低いレベルに合わせて、実装が冗長になり続けます。保守性は下がり続け、エンバグの種を植え込んでいくようなものです。
どんどん水ぶくれしていき、ある規模を超えると、今度はリファクタンリグの妨げになります。
これだけのifの密林ですから、リファクタリングしたら全テストやり直しになってしまいますから・・・
これが『実装を人質にする』手法の典型です。保守性を悪化させることで、いくらでもカネをむしりとることができます。ソフトウェア製品の受け入れでは保守性の評価について脇が甘すぎると思います。
中にはひどい人たちが居て、
- ウチの技術者ではクイックソートの実装がわからないもんで（バブルソートにした）
- 元Javaプログラマなんでmalloc/freeでメモリリークしても見つけられないんですよ
- 原理は分からないが、こう書いておいたら動いたのでこの実装で良いはず
というようなことを正々堂々とおっしゃる。
コメント