仕様決定そしてデバッグにおける勘

自分のデバッガ歴は20年程度だが、かなりディープな部分のバグ取りなんかをやっていたので、ソースコードレビューなんかについては、かなりの勘がある。
まず、仕様決定において、「なんだか気持ち悪い」と思った個所はまず間違いなくトラブルとなる(もちろん何も感じなかったところがトラブルになる事もあるんだけども)。データの流れとか、処理の流れみたいなものが見えると言えばいいのか、なんか変なものを直感で感じるらしい。それと、平気で実現不可能な処理を仕様書に書いてくる人が多いけど、30秒考えを巡らせば判る問題なんだから、ちゃんとやってほしいと思ってみたりする。
処理の仕組みが2分考えて解らない個所は、多分何らかのロジック抜けがあるか、または理論圧縮が可能だ。
ほぼ100%大丈夫な機能は、絶対ダメな機能だ。0.001%でもまずい可能性があるならやり直せ。絶対そこでバグる。マルチタスクがデフォなこの世の中でクリティカルセクションを甘く見すぎる。データをDBから取得してからそのレコードにロックをかけているみたいなもんだ。ウェブ上のカウンタがよく壊れると嘆く人が多かった時代が懐かしい気もする。singletonのダブルチェック問題には即座に気付けなかったが、コードは本当に常に正しく動くのかとちょっと疑問が残った覚えがある。相当に運が悪くなければ大丈夫という発想をするプログラマは顔を洗え。
ソースコードレベルで同じ処理が3度出てきたら、プログラマの質を疑え。絶対どっかでミスしてる。
いくらコメントに長々と注意事項を書いても、ダメと書いてあるデータの組み合わせはやってくる。マーフィーの法則みたいなもんだな。
色々考えると、意味の判らんバグっていうのは意味の判らんアルゴリズムから出てくるもんだ。構造が明快ならバグも明快。
バグはソフトだけとは限らない。OS、ファームウェア、場合にはVM、ハードウェア。毎日一定時間帯に不安定になるソフトウェアの原因が電源電圧低下だったり。今時はそう無いけどね。