klog/essay101

OSASK-WikiのKの落書きの過去ログ

• 本家：OSA:K
  • 過去ログにコメントしたい人も、本家のこめんと欄に突っ込んでください。
    • そのうちKによって下のこめんと欄に移動しますので。

僕のデバッグのやり方

• (2005.04.30)
• 今月の体験から、僕のデバッグのやり方は他の人とは違うかもしれないと思ったので、ちょっと書いてみます。
• 普通バグが出ると、デバッガなどが使えない場合は、いわゆるprintfデバッグを試みます。怪しい変数を表示させて観察しよう、ってことですね。これに限らず、本来のコードのほかに、テスト用のコードを書き足りしたり、もしくは書き換えたりすることって、よくやると思います。
• たいていはこれで原因が判明するのですが、たまにそうやって観察すると変数は全く正常で、さらに観察コードが挿入されていると、動作まで正常になってしまうという、そんなことがあります。しかも憎らしいことに、テスト用のルーチンを削除すると、また誤動作に戻るわけです。なんか量子力学の観測に関する定理みたいな不思議な状態なのです。
• こうなると、まずみんな頭を抱えるのところまでは同じだと思うのですが、僕以外の人たちは、この状況に遭遇すると、このアプローチでの追求をあきらめてしまうようです。で、ソースを全部読み直して怪しいところを探したり、別のデバッグ方法を考えてみたり、そういう方向に進もうとするようです。
• でもこれはこれでいいかもしれません。むしろ僕の方法よりも早く解決するかもしれないです。以下の話は、僕のやり方のほうがいいとか悪いとかではなくて、デバッグのやり方だけを見ても、僕の性格が出ているのかなあと感じただけなのです。
• で、僕の場合はどうかというと、うまくいったコードとうまくいかないままのコードを徹底的に比較します。うまくいかなかった原因が何かなんてことは、とりあえずどうでもよくなっていて、とにかくうまく動かすために最小のパッチを作ることだけを考えます。デバッグ表示する変数の数を減らしたらどうなるか、他の変数を表示させることでは代用できないのかとか、たとえばそういうことです。追加したコードを一つずつ取り除いて、様子を見るわけです。
• それがわかったら、その時点で初めて、なぜこの不可欠な追加が必要なのか、この追加によってどんな動作上の違いがもたらされたのだろうかと、ひたすら推理します。推理ができあがってくれば、それを確認するための実験もします。
• そうしていうるうちに、たいてい原因に思い当たって、デバッグは完了します。
• 結局僕の考えでは、「テストコードにしたら動いた」という情報は非常に重要な情報で、途方にくれる必要なんてなくて（まあでも、やっかいなバグであることに違いはないので、遭遇するとそれなりには途方にくれます）、ここからひたすらに突き進むぞー、という感じなのです。
• 読み直してみたら、なんか僕って、猪突猛進というか、壁に当たったら、意地でよじ登るというか、まあタフといえば聞こえはいいけど、ちょっとバカですね（笑）。壁を迂回すればらくに片付くことだってあるだろうし、せめてはしごで乗り越えるとか、そういう感じで、普通の人みたいになんかそういう機転をきかせるほうが、かしこそうだなと思いました。