精神と時のblog

明日が来年ならデーモン閣下と同い年になれると思っているおじさんの駄ブログ

戦う前にまず観る....そして平和は突然訪れる

んまぁガツガツとリリースに向けて

評価チームが動いているわけです。

 

そんなところに突然致命的なバグ報告。

しかも設計側からこんなの見つけちゃったと。

 

焦る焦る。

根本的な設計に関するバグ。

症状だけ見たらもう設計し直し。

論理的に成立してない訳。

外部要因とは言え、なぜあっちは

こんな仕様(暗黙)にしたのか。

 

それはさておき、まず最初に考えるのは

論理的に成り立つ設計ができないか。

 

ひたすら変更のための情報を集めながら、

頭の中では設計している。

 

ただし一方で評価チームは彼らなりの

日程もあるわけ。

この案件終わったら別の案件へと。

同じテストケースを再度こなすのは

到底無理な訳で。

 

そこで考えるのは、報告されたケースのみに

影響する修正。

いわゆる蓋をするってやつ。

 

とはいえ設計側のテスト工数も

バカにならん。

 

あーと頭を抱えていたところ、

サッと言われた一言。

 

「そもそもこれリリース版で起きるのか?」

 

ハッとしましたね。

 

「評価結果を台無しにする前に、まず自分

 達でリリース版で起こりうるかの調査が

    先決じゃね?」

 

確かにあんなゴリゴリ評価を進めている

彼らがこの問題を見逃すだろうか。

 

見つけちゃった人に、

よく聞いたら開発版でのみ発生と。

 

リリース版で再現させようにも

なかなか再現できないと。

 

こうなったらロジックでなくタイミングで

発生しえない事を証明するしかない。

 

ひたすら回数を重ねた結果、

リリース版ではタイミング的に

ほぼ再現しえないことが

分かってきた。

コード見て、タイミング的に起こるとしたら

ハード異常だ。

 

....

 

変えない努力も必要やね。

ソフトウェアは論理だけではなかった。