五十嵐　悠紀

計算機科学者、サイエンスライター。2004年度下期、2005年度下期とIPA未踏ソフトに採択された、『天才プログラマー/スーパークリエータ』。日本学術振興会特別研究員(筑波大学)を経て、明治大学総合数理学部の講師として、CG/UIの研究・開発に従事する。プライベートでは三児の母でもある

プログラミングの本は多々出版されていますが、デバッグの本はあまりありません。また、プログラミングは大学の授業や企業セミナーなどでも習得できますが、デバッグを教えてくれる教室などはあるのでしょうか？

デバッグさえなければプログラミングは楽しいのに、と感じているエンジニアは多いと思います。しかしデバッグは避けて通れないのも事実。そして、おそらくみんな、自己流で身に付けていくものだと思います。

私もそんなデバッグに悩まされている一人。IPAから「天才プログラマ」と認定されてもなお、デバッグには悩み続けています。しかしプログラミングを初めて早10年。最近はどこにバグが潜んでいるかわかるようにもなってきました。

そこで今回は、わたしが日ごろ気を付けているデバッグの方法についてここで紹介します 。

バグ発生の要因はたいてい「思い込み」にアリ

◆可視化する
◆とにかくルーチンを書いたら毎回動作確認するクセを付ける

まずはこの二つが何より大事です。一口にプログラミングと言っても、一人で最初から最後まで作ることは意外と少ないのではないでしょうか。例えば会社や研究室の先輩から受け継いだソースコードであったり、自分が数年前のプロジェクトの際に書いたコードだったり、誰かの書いたライブラリを使ったり・・・。

何だかんだで、バグが最も多く発生するのは、何が起きているかを理解せずに、「ここのルーチンはこうなっているはずだ」と思いんでいる箇所です。だからこそ、それぞれのルーチンがきちんと動作するのか、何のデータを持っているかを把握することが重要になってきます。

とはいえ、これが難しい。特に可視化コードを書くのがめんどくさい作業だったりします。わたしは3次元コンピュータグラフィックスの研究が多いので、どのような状況になっているのかを可視化するためのコードを書くのに、何時間も、時には一日つぶれたりもします。

けれども、これをしないとデバッグに二日つぶれたり、一週間つぶれたりするのでデバッグのための可視化コードを書く時間を惜しまないことが大事です。

もちろんprint文でも十分な場合も多いでしょう。とにかく、ルーチンを書いたら毎回動作を確認するクセを付けましょう。インターネットからソースコードを検索して拾ってきた際にはなおさらです。企業ではこのような「拾い食い」はないかもしれませんが、研究していると他人の書いたインターネット上のコードを使わせてもらうことはよくあるので、要注意です。

前提条件が違ったりするため、きちんとデータの入出力などの動作を確認してから使う必要があります。ネット上に公開してあるソースコードだから動作保証は大丈夫！というのも「思いこみ」。バグの発生源になります。

時間を掛けてテストコードを書くことが、翻ってデバッグ時間短縮に

また、オブジェクトを作成している場合には、オブジェクトに正しい値が入っているかどうかも確認する必要があります。特にオブジェクトをコピーして使っていたりする場合は要注意です。

中のデータ構造は一緒のものをコピーしていてもオブジェクト自体が別のものを指していたりすることもあります。print文やテストコードなどをまめに書いてチェックすることは大変だし、時間も掛かるので遠回りのように思えますが、案外デバッグの近道です。

ステップ実行ができる環境であれば、それを利用するのも手です。わたしはあまり利用せず、自分で現状がどうなっているかを可視化するコードを書くことが多いですが、Visual StudioやEclipseなど、開発環境次第ではステップ実行が可能なものも多いです。

◆隣の人に触ってもらう

自分ではプログラムが完成した！ と思っていてもバグは潜んでいます。開発者自身が内部をきちんと理解しているからこそ、自分でテストをする際にもそれに合わせた入力や方法を採ってしまいがちです。

大学の研究室では、いきなり大人数でのユーザーテストをしたり、インターネット上で公開したりせずに、まずは隣の人に触ってもらうことをオススメしています。こうすることで、自分では想定していない入力などをあらかじめ知ることができるからです。

自分一人で開発したプログラムは、往々にして”職人コード”になってしまいがち。隣の人でも家族でも、一人でも二人でもいいので触ってもらい、バグチェックするように心掛けましょう。

「バグを取る前にバグを入れない」ことこそ、最強のデバッグ術

◆プロファイラを駆使する

また、処理の時間が掛かりすぎる時にはプロファイラが便利です。

処理速度を向上させるためにはアルゴリズムを根本的に変更したり、クラスを作るのを極力減らしたり、アセンブラを知っている人はfor文を使っている部分を書き下したり、などの工夫を施すと思います。が、まずプロファイラを使って余分な処理、何度も繰り返している処理などを効率よくできるかどうか検討してみるのが良いでしょう。

時間の掛かっている順にソートされるので、そこをつぶしていくと面白いように速度が速くなります。あっという間に1ケタ、2ケタ処理速度が変わることもあったりします。処理速度なんか関係ない！と思っている人も是非使ってみてください。面白いように早くなりますよ。また、コードがスッキリするので、デバッグもしやすくなります。

わたしはJavaでプログラミングをしているのでJRatを使っています。「プロファイラ」で検索をするといろいろでてくるので自分にあったものを選ぶのが良いでしょう。

プログラミングをしている際には早く機能を実装したい、アルゴリズムを試してみたいと気持ちが焦り、デバッグはついつい後回しにしがちです。わたしもよく、「// TODO あとで～する」などとコメント文を入れて、さっさと機能を実装してしまったりするのですが、たいていこういう部分にバグが入ります。

建築物と一緒で、足場をしっかり組んでいかないと結局高い建物は作れないのです。逆に、最終的な高さに応じて足場の強さは決めれば良いという考え方もあります。

製品として世の中に出すためにはバグは混在していてはいけませんが、研究段階のプロトタイプとしてそのレベルを要求していたら、いつまでたってもバグ取りばかりになってしまい、肝心の研究が進まなかったりします。

上司に「こういうことがしたい」と伝えるだけであれば、その部分だけコーディングすれば良い、ということもあるでしょう。

◆眠い時はコードを書かない

これが、わたしが一番気を付けていることです。どんなに頑張っても眠いときは間違えます。ここまで、効率良くバグを取り除く方法をいろいろと上げてきましたが、最も大事なのは「バグを取る前にバグを入れないようにすること」なんですよね。

日ごろの業務に追われていると、だんだんと睡眠時間が取れなくなり、結果、バグが多発する事態に陥ってしまうことがままあります。こう言うと当たり前に聞こえますが、作業効率を落とさない働き方を心掛けることこそ、最強のバグ対処法なのかもしれませんね。