バグは至るところに、しかも堂々と潜んでおり、自信満々なプログラマーほど、目の前のバグに気付かないものです。「バグ検出ドリル」の第9回では、比較的大きなソースコードである迷路探索プログラムに潜むバグを見つけ出してください!
本連載では、エンジニアのバグ検出力の向上を目指し、バグ入りの問題を出題して読者のみなさんに見つけてもらいます。本コラムをきっかけに、より高いレベルのエンジニアを目指していただければ幸いです。
前回は30行の超小型プログラムを出題しましたが、今回は約200行の比較的大きなソースコード(迷路探索プログラム)に挑戦してもらいます。仕様も少し大きいのですが、類似の処理を4回繰り返すので、見た目ほど複雑ではありません。プロの技術者であれば、この程度のプログラムはゼロから開発しても3時間、机上デバッグに1時間というところでしょうか。おそらく、30分程度でバグを見つけられると思います。
どんなに簡単なプログラムでも、バグなく作成することは簡単ではありません。バグは至るところに、しかも堂々と潜んでおり、自信満々なプログラマーほど、目の前のバグに気付かないものです。
デバッグの基本的な心構えは「渡る世間に鬼はなし(動くソフトにバグはなし)」ではなく、「人を見たら泥棒と思え(ソースコードを見たらバグと思え)」です。とにかく、全てを疑い、自分の論理的な思考に照らして、細かくチェックしましょう。
バグを見逃す理由として、プログラマーの「すぐに忘れる」と「思い込み」があります。「すぐに忘れる」ですが、大半のエンジニアは、自分の書いたコードを3日も過ぎると忘れます。もう一度コードを見直すと「なぜこんなプログラムを書いたのだろう」と思うことも少なくありません。
一方の「思い込み」では、全く同じプログラムをデバッグする場合でも、自分のソースコードは、「正常ケースがちゃんと走っているからバグはない。俺様が書いたソースコードは間違っていない」とのバイアスが多少、混じって見逃しがちになります。しかし、他人が作成したプログラムに対しては、「粗捜しをしてやろう」との「エネルギッシュな意地悪心」が湧いて全てを疑ってかかるため、バグが見つかります(ちなみに、「粗捜し」や「重箱の隅を突つくこと」を英語で「microscopic scrutiny」と言います。顕微鏡で細かくチェックする感覚ですね)。つまり、気持ちを「他人の視線」に切り替えてデバッグすることは、意外に効果があります。
Copyright © ITmedia, Inc. All Rights Reserved.