製品は違えど、俺の仕事はこういった事態を未然に防止すること。利用者ではなくメーカーとして人ごととは思えん。全国の職業プログラマも、同情を禁じ得ない人、震え上がった人、いろいろだろう。
”ネガデータに「ある長さ、ある件数」といった条件が重なった時、データが読み込めなくなる”というのはよくある話で、原因としてありがちな事例の１つを野球で言えばセンターとライトがお互いに「相手が受けるだろう」と思って真ん中ポトリ、あと１センチレフト側だったら、またはあと１センチライト側だったら捕れたのに、みたいなイメージである。もうちょっとプログラム的に説明すれば、たとえば
(1)ネガデータの送信残量Aを調べる
(2)ネガデータの一部をある一定のBバイト、パケットとして送信する。ただし、A＜Bのときは、Aバイトだけ送信する。
(3)AからBを引き、それを新しいAとする。
(4)Aが0以上ならば、(2)に戻る。そうでなければ終了。
というコードが記述されていたとする。ここで(2)の送信の都合上、0バイトではパケットが送れずエラーになったりする仕組みだったりすると、このコードにはバグが潜んでいることになる。(2)で「0バイト送信」ができないのなら、(4)は「Aが0以上ならば」ではなく、「Aが0より大きければ」が正解である。さもなくば、AがBの倍数の場合、最後の転送で(2)は必ずエラーになる。たとえばBが64kバイト(65,536バイト)だとすると、Aが65,536の倍数だった場合にはエラーになる。ただし65,535でも問題ないし、65,537でも問題ない。
これをテストで見つけようとすれば最低65,536通りのテストをすればバグは検出できるが、実際のプログラムはこんなに短くない。他にもマトリクスの関係になる条件が何万と重なり、実際のテスト項目はあっという間に数千万件に達する。
ではどうするか、そこは各メーカーのノウハウと思うので詳しく書かないが、この手のセミナーや教科書はいくつか存在する。しかし、納期や予算、プログラマの健康問題という制約の前には教科書すら戯れ言に見えてくる。
うまく動いて当たり前、事故を起こせば吊し上げ、割に合わない商売かも知れない。でもそういう職業も社会には必要なんよ。
それにつけてもこういう事故で毎回思うのが、事故原因となるバグが明らかになってから「なぜそんな単純なバグすら見つけられないの？」と得意顔で話す奴。いや、上司に多いんだけどね（笑
後出しジャンケンと同じ。答えが解ってからなら、そのセリフは誰でも言えるよ。バグが出る前に、これから発生するバグを予想してみなよ。と言いたいのをしばしばこらえる俺。そこで反論したら俺は所詮、目の前にいる上司にも劣る人間なのだという気がして。
コメント