概念的・抽象的な指針ではなく、実践的・具体的な方法論を教えてください。
No.1
26
2
60pt
フラグを使うプログラムは私見ですが、設計不足の場合に多いと思います。
つまり、最初Aという処理で良いと思っていたところ、A内でAA、ABと処理を分ける場合が見つかり、フラグを立てることでAA,ABの何れを実行するか分けるわけです。
対策としては十分に事前の設計・レビューを行なえば自然とフラグは必要なくなります。
例えば一つのモジュール内にON/OFFのフラグが10個あった場合、最大でも1024通りの状態が存在し、カバレッジを１００％にするためには1024のテストケースが必要になるわけです。
実際にどれだけのパスが存在するかはMcCabeの複雑度を計測することで判ります。
McCabeの複雑度を計測してくれるフリーのツールもあります。
SourceMonitor
http://www.campwoodsw.com/sourcemonitor.html
常に複雑度を計測して多すぎる場合はリファクタリングを行なうと良いでしょう。
McCabeの複雑度に関しては以下のように言われています。
10 以下であればよい構造
30 を越える場合，構造に疑問
50 を越える場合，テストが不可能
75 を越える場合，いかなる変更も誤修正を生む原因を作る
30
30
2
1
1
回答ありがとうございます。
ただ、対策として、「十分な事前の設計・レビュー」よりも、さらに実践的・具体的な方法論が伺いたいです。
もうすこしミクロな、コードレベルの観点で内容を頂戴した方がよいのかもしれません。