「まずは可視化コード書きから」めんどくさがり屋必見！できるだけ作業時間を減らすデバッグ術

OSS

技術解説

連載 :

エンジニアtype

2012年7月20日(金)

『エンジニアtype』編集部

天才プログラマー・五十嵐悠紀のほのぼの研究生活

筑波大学システム情報工学研究科コンピュータサイエンス専攻非数値アルゴリズム研究室(NPAL)
五十嵐　悠紀

2004年度下期、2005年度下期とIPA未踏ソフトに採択された、『天才プログラマー/スーパークリエータ』。筑波大学システム情報工学研究科コンピュータサイエンス専攻非数値アルゴリズム研究室（NPAL）に在籍し、CG／UIの研究・開発に従事する。プライベートでは二児の母でもある

ちょっとめんどくさいけど、絶対にやった方が良いデバッグ。身に付け方は、人それぞれ？（ photo byTomotaka）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

◆隣の人に触ってもらう

"職人コード"になってしまわないためにも、周囲のプログラマでも理解できるかどうかを尋ねてみよう（photo by Breyten Ernsting）

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

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

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

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

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

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

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

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

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