メタデバッグ

今回はメカAGさんのブログからご寄稿いただきました。
■メタデバッグ
「メタデバッグ」という言葉を聞いたことがあるだろうか。多分ないだろう。たったいまオレが作ったw。でも長年それなりの規模のソフト開発をしている人間ならわかってもらえるのではなかろうか。

デバッグをするには再現手順を確立する事が大事。よくエンドユーザがレポートしてくる「ときどきおかしくなる」では、デバッグができない。具体的にどういう手順でどう操作した時にそうなるかを、調査しなければならない。その不具合を確実に生じさせる方法。それがわかれば、あとはひたすらコードを追いかけていけば、バグは取れる。

しかし実際にはこの再現手順の調査が難しい。微妙なタイミングがあったり、メモリの解放ミスやポインタ操作のミスは、その場では直ちに不具合が起きず、全然ほかの箇所にひっそりと悪影響を与えている事が少なくない。すると不具合が起きた箇所と、その原因がぜんぜん違う場所というのも珍しくない。

昔に比べれば、そういうデバッグしにくいバグが生じにくいようにシステムやプログラミング言語も改良が加えられているが、それでもゼロにはならない。

　　　*　　　*　　　*

で、そういう時はひたすらコードを追いかけていても、埒が明かなかったりする。いわば推理小説の名探偵並みのひらめき・推理力が必要。そういうものに頼らなくてはいけないのが、そもそも工学として失格なのだが、どうしようもない。

推理というのは結局はデータの分析力で、重要なのはデータを集めること。仮説を立ててもしそれが原因なら、現象としてこうなるはずだから、操作してみ実際にそうなることを確認せよ、と。この場合も確実に再現するなら1回やれば十分なのだが、再現性が悪いと、数をこなさなければならない。大勢のテスターの人を動員して操作してもらう。人海戦術。

この時怪しい箇所も1箇所ではないから、複数の仮説を立てておくことが重要で、たとえば1つの仮説の証明が3日でできるとすると、3つの仮説の証明もやはり3日になることが多い。つまり1度に複数のテストをした方が格段に効率がいい。もしこれを順に1つずつ検証していくと、3日x3回で9日もかかってしまう。

　　　*　　　*　　　*

さてここからがポイント。この手のデバッグに慣れてない人は、一番怪しそうな箇所を思いつくと、それだけしか意識が行かなくなる。それが当たればいいのだが、外れると2番目に怪しそうな箇所を考えて、それをテストする。それがダメだと3番目。結果的に3回も人海戦術を導入しなければならず、時間もコストも効率が悪い。