「あれだけやったんだから」と思えるぐらいの気持ちを持ちたい

　板情報を配信するプログラムは本来、1銘柄当たり1280バイトの作業用メモリー領域を2万8000銘柄分、合計3万5000Kバイト確保するよう記述しなければならない。だが、1銘柄当たりのメモリー領域を誤って4バイトとしてしまったため、プログラムは本来の320分の1の109.375Kバイトしか確保しなかった。結果として89銘柄以上の板情報の問い合わせが同時に発生すると、作業用メモリーが足りなくなり、情報配信システムがダウンした。

ニュース - 東証のシステム障害、設定ミスをテストでも見抜けず：ITpro

はてなブックマークにも書いたんだけど、つまりあれだ。

    struct Ita *pIta;
    size = sizeof(*pIta) * nTotal; // correct

とすべきところ

    struct Ita *pIta;
    size = sizeof(pIta) * nTotal; // wrong

としちゃったんじゃないかと。いや、根拠ないけどね。なんとなく。

これを見て自分のコードを確認したのは私だけ！？：）

　現在、派生売買システムで扱っている銘柄数は約2万銘柄。板情報を配信するシステムは、今後の銘柄増を見越し2万8000銘柄まで対応可能となっている。だが「そのほとんどが株式のオプションであり、取引頻度はあまり高くない。板情報の問い合わせがあるのは通常数100銘柄程度」（東証広報）だった。そのためか多数の銘柄に対応したテストケースを用意しておらず、20日に取引参加者を交えて実施したテストでもミスを発見できなかった。

実情は知らないので、的外れなこと言ってると思うけど、これを見て思ったこと。

テストって、ほんと大変なんだ。いろんなケースを想定し、時にはプログラマの気持ちになって、悪そうなところを探す。マメじゃないyasuhoには絶対ムリです。＾＾；

それでも抜けは出てくる。プログラマならコードを見て「これよく今まで動いてたなあ」なんて思ったことは一度や二度ではないはず。プログラムは偶然で動くっていうのが今までの経験から得たyasuhoの持論。いやマジで(笑)

テストも大事だけど、コードレビューも同じぐらい大事だと思う。コードを1ビットでも直したら、しつこいぐらい検証した方がいいんだ。「こんな簡単な修正、絶対間違えないって」そう思っていたとしても、だ。

ありとあらゆる知識・経験・開発技法を使って製品をリリース。それでもバグはなくならない。だから大事なことは「あれだけやったんだから」と思えるぐらいの気持ちとバグが出た時の対応。素早い対処はもちろん大事だけど、問題を正しく見極めることはもっと重要。最終的にはプログラムの品質は開発者への信頼だと思うから。

もちろんそれは理想論で、現場じゃそんなうまくいくことは少ない。でも「あの時もっとテストしておけば」「あのバグ、うやむやにしなきゃよかった」後でそんな後悔はしないようにしたい。そう思いながら今日もコードを書いている。

---

ソフトウェアの品質は作ったプログラマへの信頼度に依存する