網羅テスト

次から次へと・・・

今度は、ケーキ作りに例えて・・・。ケーキを加工する原価計算のプログラム、だとして(最初は、納期管理だけのつもりだったんだけど)、最終加工工程に、ケーキのデコレーションがある、と、後から知り、このデコレーション、特注なのか、「原価」に含める場合と、含めない場合とがある、という想定、で、含めない場合には、デコレーションなしの段階で「完成品」になる、けれども、かかった費用と、売値は管理したい。この「含めるか」「含めないか」は、クリック一つで対応可能にする、という感じで・・・。

ここで、「完成品」の売り先を辿るということになった時点で、その一連の製造工程全部へのリンクで、完成品の売り先が決まって、そのデータをくくりつけた後で、デコレーションを特注扱いにする、というチェックマークがクリックされると、「完成品」のリンクが一つ前の、デコレーションなしの段階のフェーズに括りつかないと、おかしくなる。状況によっては、コンパウンド・ケーキだけ、あるいは、スポンジだけでも「売り物」にする場合があるため、それが可能な構造にはしたのだけれども、その最終工程の「デコレーション」だけ原価から外す場合があり、かつ、後からチェック一つで「含める」ように戻すことも可能、というあたりで、組み合わせが煩雑になって、頭を抱えた。「一旦、特注にする」と決めたら、変更しないのならば、まだ、データの一貫性は保てる。後から「特注扱いをやめる」となると、データベース内の関連する情報を全部「設定し直し」しないとならない。

さらに、デコレーション前の段階で、ケーキが4分割とか、6分割されて、分割した状態で販売されることになっても、その一切れ当たりの原価が(4分割、6分割されて)計算されなければならない。今度は、ホールではなく、分割された状態が「完成品」。で、さらに後からその別々に発生するデコレーション(そのうちの一つには、「誰それちゃん、誕生日おめでとう」が載ってくる、とか・・・)についてのコストを、クリック一つで、含めたり、含めなかったり。

そうなると、原価情報、納期情報をどこに括り付けるかが、最大の問題。ここまでの流れが、最初からわかっていたら、そういう設計をしていたんだけれども、最終段階の仕様(単に、ホールケーキが最終系)がどんどんと細かくなって、パッチワークが追いつかなくなった。そこに、網羅テストで、「後から、特注扱いにしたり、そのチェックが外れたりした時に、どう処理するか」で、今の基本設計では対応し切れないことに気付いてしまった・・・

・・・あ、できるか。単に面倒臭いだけで。一旦保存したデータを、再計算して、全部、辻褄が合うように書き直せばいい。(安倍総理がよくやらせている奴、だな、たぶん。)

この辺の仕様、最初からわかっていたら、対応が容易なスキーマを描いたんだけれど。ただ、今の延長でも、ちょっとチェックを入れたり、外したりするたびに、全部の流れを読み直して、全部の関連データを読み直して再計算させるためのプログラムを追加したらいい、”たったそれだけのこと”ですかね。基本設計が対応し切れなくなって、そこから書き直す時間がないなら、力任せでアルゴリズムで対応する。(バグが出たときに、一番面倒臭いパターン。)

とにかく、最初は、ケーキのホールが仕上がったら、それで終わりだと思って設計した。カットされて、個別に売られることがわかったあたりでも、まだ対応できると思った。その最終工程に「デコレーション」が追加されて、そのコストが、加算されたり、されなかったり、切り替えられる、ってな辺りで、組み合わせが猛烈に増えて、基本設計が論理破綻を始めた。

とにかく、それが今の現実なんだから、if / else がどんなにややこしくなろうと、全部ロジックだけで辻褄合わせをやる。それしかなさそうだ。

最悪だったのは、やはり「段取り」の悪さ。教訓にしては、痛すぎる。