キャリアVol.37

「まずは可視化コード書きから」めんどくさがり屋必見!できるだけ作業時間を減らすデバッグ術【連載:五十嵐悠紀⑬】

(by Tomotaka)
ちょっとめんどくさいけど、絶対にやった方が良いデバッグ。身に付け方は、人それぞれ?( photo by Tomotaka

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

◆隣の人に触ってもらう

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

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

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

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

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

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

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

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

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

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

作る建物が高いか低いかで、足場をどれだけ固めるのかが決まる(photo by DecoJim)
作る建物が高いか低いかで、足場をどれだけ固めるのかが決まる(photo by DecoJim

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

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

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

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

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

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

この記事が気に入ったらいいね!しよう

エンジニアtypeの最新情報をお届けします

RELATED POSTS関連記事

JOB BOARD編集部おすすめ求人

この記事に関連する求人・キャリア特集


記事検索

サイトマップ



株式会社富士通エフサス【ポジションマッチ登録】 オープンポジション

株式会社ローソンエンタテインメント データ解析・運用/業務未経験OK/人…

森永乳業株式会社 システム開発(web・オープン系・新規技術)◆ITを活…

株式会社コロプラ【ポジションマッチ登録】 オープンポジション

株式会社日進サイエンティア PM候補/設立以来、無借金経営/想定年収600…

旭化成株式会社 プラントエンジニア職

アクサス株式会社 システムインテグレーション事業部 エンジニアリンググ…

ゼネラルエンジニアリング株式会社【(株)マイナビの100%子会社】 モノ…

ソニーエンジニアリング株式会社 [電気設計] ~回路設計/デジタル回路、ア…

株式会社ZMP エレキエンジニア◆ロボット製品に携わる◆平均残業20時間…

SIerって本当にヤバいの? ひろゆきが語る、業界ごと沈まな...

4年後の「Badシナリオ」から考える、2020年代も重宝され...

シリコンバレーで働いて気付いた「技術力向上」だけに固執するエ...

英文メールでよく見る「略語」の意味は? 海外エンジニアに聞い...

「視点を変えればエンジニアのキャリアは激変する」LIFULL...

エンジニア転職フェア開催 IT&モノづくりエンジニアを求める優良企業が大集結!