得意先マスターの話。得意先コードと得意先氏名があり、得意先コードがキーになっているマスタで、受注伝票はこの得意先コードをベースに蓄積されていく。簡単明瞭な仕組み。
自分から火をつける設計者がいたりするから、面白い。<-コラw
受注データが存在するのにマスターの削除を許している。 これも問題だがそれ以上に、一度削除した得意先のコードを新規得意先に使いまわししている。
稼動後暫くして、複数の得意先データが混在して分離できない。と騒いでいる。
言い訳: 旧システムがその仕様だった。踏襲しただけなので俺の責任でない。
こんな設計者は要らないんですが。なぜ存在できているのだろう。
運用仕様のレビューなど行われないの? そこそこの規模だとレビュー行われるが、小規模システムだと担当者任せになっていて設計の妥当性のチェックする機関がないのですね。
いくらプログラムが優秀でも設計がグシャならシステムはグシャです。小さなシステムでもシステムレビューする仕組みが根付くことは出来ないものでしょうか。
マスターを論理削除する仕組みでも、削除データの復活を許すときもよくよく考えないと同類のグシャは起こり兼ねません。
姉歯設計士は意識的に行ったので悪人になったが、上記の設計者は知識不足で本人は善意で行っているので始末が悪い。