SE徒然日誌

昨日の不具合の原因は、簡単に言うと他のプログラムとの連携ミスでした。

また、今日になって問題となったデータが他の処理に対しても影響を
与えていることがお客さんの連絡で発覚しました。


修正対象となったプログラム全てが単独（もしくは通常の運用）だと
正常に動きます。ただ、今回は年末/年始の忙しい時期に変則的な運用を
したことにより発生しました。



確かに結合テスト・システムテストが十分じゃなかったことによる
障害かもしれません。

けれども過去の障害履歴を追うと、他の部分の連携や単独実行時に
同様の障害が発生していて、修正している形跡があります。



障害だけに限らず、仕様変更等である部分に不具合が発生した時、
スポットのみを修正してよしとすのではなく、一人でも
「他のPGで同じようなことをしていないか？」
「変更後のデータが流れていく先のPGで問題ないか？」のように
もう一歩先を考えてくれていれば、未然に防げたのでは？と思います。



■補足
やっつけ仕事でプログラム修正をされると、
・ソースが汚い。
・目の届く範囲での整合性しかとられない。
・同一処理のはずなのに複数プログラムで複数の名前で存在する。
・辻褄合わせに最後に値をセットし直すもんだから、ロジックを
　追っても、どれが正しいのかよく分からなくなる。
→下手に直すと二次災害が発生するので非常に保守し難いです。

ひどい奴なんかは、こんなことを言います。
「動いている箇所を修正するとテストがすごく大変なんで、
　元のソースはいじりません。」

実際に問題が発生したら、場合によっては不正なデータであろうが
登録済みのデータは削除できません。

本来あってはならない状態を認めた形で、今後は認めないように
プログラムを修正しないとならないので、何十倍もコストが発生します。

（それ以前に、何処を修正すれば直るのかソースから判断できない
　プログラムにも問題はありますが。）

…おかげさんで、明日は出勤です。（泣）