デバッグのご相談ならお任せを
最終更新日: 2007-12-22
WEB+DB PRESS Vol. 38 に向けて書いた記事の元の原稿です。
今月号から「プログラミングの光景」と題して、連載することになった高林と申します。プログラミングは趣味として、仕事として、かれこれ10年ほど行ってきました。本連載では、「プログラミングに関する雑多な事柄」について書く予定です。
第1回の今回はプログラミングとは切っても切れない関係にある「デバッグ」について取り上げてみようと思います。
ソフトウェア開発において、デバッグに要する時間は相当のものです。プログラマとしては「いやいや、自分はそれほどデバッグに時間を使ってないよ」と否定したいところですが、冷静に考えてみると、現実には自分が考えているよりも (そうであって欲しいと考えているよりも) デバッグに時間を要しているように思えます。それに、バグは他人が書いたコードに混入していることもあるので、たとえ自分がバグを入れなくてもデバッグするはめになります。
デバッグの方法論についてはさまざまな文献で取り上げられています。デバッグで難しいのはバグの原因を見つけることです。原因さえ特定できてしまえば、修正自体は大抵の場合、簡単に片づきます。バグの原因を見つけ出す主要な方法には次のようなものがあります。
最後の、「身近な人に相談する」に関しては、状況を説明することが重要なので、相談相手は人ではなく、ぬいぐるみでもよいという説があります。
デバッグのご相談ならお任せを
デバッグの時間を減らすには、バグを出さないことに越したことはありません。バグを予防する主要な方法には次のようなものがあります。
ユニットテストの重要性については近年、多くの文献で強調されており、私の経験としても、ユニットテストのおかげでデバッグに要する時間はかなり減ったという実感があります。
といいつつも、「このくらいの小さな関数ならテストを書かなくてもいいだろう」とついさぼってしまい、何時間もプログラムを走らせたのちに結果が間違っている (バグっている) のに気づくというときがいまだにあります。
また、大規模なデータを処理するプログラムを開発する上では、いきなりでかいデータでテストをしないで、まずは小さなデータでテストをするのが効果的です。ついつい、「一発で動いたらいいなあ」という期待の元に、本番のでかいデータで実行してしまいがちですが、一発で動いたためしはありません。
通常、プログラマは大抵の問題は自分で解決しようとしますが、どうしても手に追えない場合は、周りのプログラマに救援を求めることがあります。前述の通り、他人に相談すると、説明しているうちに自分で原因に気づくことが多いのですが、中にはそう簡単には直らない厄介な問題もあります。
このようなとき、「どれどれ、ちょっと見せて」といって他人のデバッグを手伝うのは楽しいものです。どうして楽しいのか考えてみると、次のような理由に思い当たりました。
デバッグで苦しんでいる張本人と比べて、第三者である助っ人は客観的にコードを見れるので、張本人が見落としていた問題に気づくことはよくあります。また、「この挙動は以前に見たことがあるぞ」と、過去の事例に照らし合わせて勘が働くことがあります。
C++でいえば、メンバ変数の未初期化やスレッドのスタックのオーバーフローによるバグは、一度遭遇したことのある人ならば勘が働きますが、はじめてのときは厄介なバグです。ペアデバッギングはこうしたノウハウの伝承に効果的です。
ただ、助っ人としてバグを潰したときの「鼻が高くなる」の態度が鼻につくと 二度と頼まれなくなる恐れがあります。時代劇の主人公のように「名を名乗る程の者ではござらん」といって去っていくのがクールなデバッグ仕事人の態度というものです。
今回はデバッグについて書きました。次回からもこの調子で、プログラミングに関する雑多な事柄について書いていく予定です。