Mr.Tです、こんにちは。
CDと書くコードを扱う際に、CDの直指定というモノがある。
直に指定するのは、ユーザであるべきで、システムとしてあるべきではない。基本は、そう思っている。
なぜ、直指定が悪いのか？
それは、汎用性がなくなるためであり、CDの変更=プログラムの変更になるためだ。
だから、おいそれと直指定であることを選択はしない、はず。
プログラムの変更は、あちこちに分散している場合だと、そのあちこちで変更する必要が出てくる。
変更漏れがないのかチェックする必要がある。
それを変更したら変更した部分のテストの必要が出てくる。システムとして、きちんと稼動するかどうかのテストも
必要になる。
いったい、それをテストして、確認するのにどれほどの手間がかかるのか、わかっているのかわかっていないのか。
これから先、そのCDが使われなくなったらどうするのか？
似たようでちょっとだけ違う意味のCDが増えたときは、やはりIF文が増えるのか？
ごめんだ、いやだ、やりたくない。そう思うはずだ。
ビジネスロジックをコードに落とし込むときは、がちがち指定にするのが、わかりやすいかもしれないのだが、
かといって、データとプログラムを分離しないとメンテナンスが困難になる。汎用性がなくなる。一般化したい。
ユーザから、「こういう商品のときは、こうやってすれば簡単じゃないか」という要望があったりするが、そういう場合は
きわめて直感的に直指定の方法を提示する。しかしプログラマは、直指定をするのは結果的に非常に労力がかかることを
知っている（はず）なので、それを忌避し、一般化するような形にしていく。
そのため新たな管理CDや、フラグが増えたりする。また、それを修正したりするための画面などなどを考えてつくったりする。
結果、ユーザに対して「こういうフラグをつけたので、この画面で修正してください」
間違ってはない。
しかし、その管理CDは、業務内で広くつかわれるようなものではなく、たった一つの帳票で出力するためのものだったり
システムとして、果たしてそれほど必要なCDなのかというと疑問だ。こんなコードをつくるより、この帳票をつくるプログラム内だけで
利用するCDを書いておけば、それですむんじゃないかと思ったりもする。
「ああ、システム内のここだけしかそういう判定はしないんだけどなぁ」というものがあったりすると、「製品指定」「部署CD指定」なんてことに
したほうが、プログラムが直感的でわかりやすくなったりするケースもある。
「どうしてこれだけのことをするのに、こんなにお金がかかるの？私たちは、この帳票一つをつくって欲しいだけなのに、
こんなフラグや、CDのメンテナンスをしなくちゃならないのか、まったくわからない。この製品のときにこうすれば
いいだけじゃないか！」
これの私なりの答えはほぼ決まっている。
「直指定はわるくない。しかし、それは最終手段だ。奥の手。それをすることで、このシステムには、もう余裕がない。
それを使ってしまうと、その後は、墓場までフォローしなくちゃならないことを忘れないでくれ」