入門 Python 3 第3版

16章デバッグ

誰もが知るように、デバッグは最初にコードを書く場合と比べて2倍も大変である。できる限り巧妙なコードを書こうとする人は、そのコードをどうやってデバッグするというのか。

—— ブライアン・カーニハン

デバッグは犯罪映画の探偵のような作業だが、自分は殺人犯でもある。

—— フィリペ・フォルテス

子どもが雨はどこから降ってくるのと尋ねてきたら「神様が泣いているんだよ」と答えたい。いい感じではないか。そして、子どもがさらに神様はなぜ泣くのと尋ねてきたら「たぶん君がしたことが原因だよ」と答えたらさらにいい感じになると思う。

—— ジャック・ハンディ

まずはテスト（「15章　テスト」）である。テストがよくできていれば、あとで修正するケースが減る。しかし、バグは発生するし、あとで発見されれば修正しなければならない。

コードが壊れた場合、大抵は直前に行ったことが原因である。そのため、デバッグは一般に「ボトムアップ」で始める。最後に書き換えたところから検討する。

しかし、信頼して動作すると思っていたものの中に原因がある場合もある。多くの人が使っているものの中に問題があるのなら、今までに誰かが気付いたはずだと考えるのは自然である。実際、こんなことが頻繁に起こるわけではない。しかし、筆者が遭遇したバグの中でも特に難しく、修正に1週間以上かかったものは、出来がよいと思っていた外部のコードに原因があった。そのため、鏡の中の自分を非難してもうまくいかなければ、次は自分の前提条件を疑う。これは「トップダウン」の方法であり、ボトムアップよりも時間がかかる。

特に悪質なバグは、別のバグを隠していたコードを修正した際に現れる。

CやC++のような言語とは異なり、プログラマが自らメモリをいじることがないため ...