私の周りで起きてきたトラブルプロジェクトを見てみると、コード内の状態管理が破綻してしまってバグ多発、というケースがほとんどのような気がする。
- 仕様変更が入る
- 仕様変更分を新たな「状態」として定義を増やす
- すでにコーディングした場所の修正を最小限にしようとして、「フラグ」を追加したりする
- そういうのを繰り返すうちに意味合いのよく分からない「フラグ」が増えてくる
- バグが発生した時に修正しづらい、修正してもデグレードする
...という悪循環。
こういうケースはウチだけでは無くてどこにでもある話しなんだろうけれど、他機能の状態まで判定して処理分岐しないといけない、なんてなるともっと話しがややこしくなる。
管理する状態の数が少なければ、テーブル化するなりという手があるんだろうが、数十にも渡る場合はどうすればいいんだろう？
ときどき聞く設計時の「モデル検査」の手法でも状態マトリクスを作成して検査するわけだけど、状態の数が増えると二次関数的にマトリクスが増えていくわけで...
根本は、「状態」を減らすことなんだろう。
「状態A=n かつ 状態B=m かつ 他機能状態C=x の場合は」というような複合条件を、一つ下のレイヤで判断させ、上位レイヤにはそれ自体の判定結果を返すようにするとか。そうすると少なくとも上位レイヤのコードは見やすくなるはず。
ただ判定処理のレイヤは気をつけないとすぐに「状態判定関数A()、状態判定関数A_forXXX()」のようにイタズラに関数が増えていって収拾が付かなくなることになりかねない。
特に仕様変更が入りやすいプロジェクトは設計時にすべてを洗い出せない分、「あとから追加」のワナに嵌りやすい。
業務アプリにしろ組み込みソフトにしろ、この辺をいかにうまく作れるかでトラブルになるかならないかの分かれ目になるんだろうな。ちょっといろいろ調べてみよう。
コメントする