机上デバッグの効果¶

机上デバッグの効果は、「事前にプログラムのバグを発見・修正することによりその後の開発工程の時間を短縮できる。」ですが、その他にも副次的な効果があります。それは、プログラム全体に精通できることです。

机上デバッグは、ソースコードを見ながらその動作をシミュレートするので、プログラムの全体像を把握することができます。その結果、大まかな処理を頭の中に記憶することができます。これにより、より早く問題を発見しその対策を行なうことが可能になります。

例えば、数万行程度のプログラムを部分的に把握していたとします。その場合、比較的単純なバグの対応はさほど難しくはないのですが、

• マルチスレッド環境で、たまに発生する問題。
• 結合試験環境で、たまに発生するメモリの問題。

といったようなちょっと厄介なバグに対応するには、局所的に把握しているのと全体を把握しているのとでは、その対応に大きな差が生じる可能性があります。

直立歩行型のロボットの開発を想像してみてください。これが非常に巨大なシステムのため、数十人規模での開発を行なっていることにします。さて、開発も徐々に進み、実際に歩かせてみることになりました。まずは直立状態から右足を前に出す。おぉ、うまくいった。それでは続いて左足を前に、と思ったらずっこけた。ということで、左足を前に出した際になぜ転んでしまうのか？デバッグを開始します。この時、ロボットの全体を把握している人には、左足を前に出す際に実は右足の位置が悪く、その結果転んでしまうということがすぐに分かりました。しかし、左足小指を担当している人には、右足のことまで思慮が及ばないため、この問題はいつまで経っても原因を特定できません。その結果、本来まるで必要のないスタビライザーを左足小指に装着したりします。

あまり現実的な例えではないように思えるかも知れませんが、これに似たようなことが現実のソフトウェア開発の場では稀に見られます。以下は、ある処理の中でおよそ関係がないと思われる変数の値によりバグが発生したりしなかったりといった例ですが、

• 何か問題が発生する。
• 調査したが良く分からない。
• さらに調査を続けたが、さっぱり原因が分からない。
• さらに調査を続けた結果、どうも問題が発生する際は、変数 m の値が 0 になっている。
• 試しに、変数 m の値が 0 の場合に処理を変更してみたところ、うまい具合に動作するようになった。
• 上司に報告「理由は分からないのですが、こうしたらうまく動作するようになりました。」上司「(納期が迫ってるしな…) じゃ、それでファイナルアンサーで」

この経緯は空想ですが、現実に「なぜここでこの変数を検査し、その結果処理を変更しているのか？」ということがまるで理解できないというソースコードは、ごく稀に存在します。

机上デバッグによって担当するソースコードを熟読することにより、担当部分全体に対し、広く深く把握することができ、その結果直接何かの役に立つことはありませんが、それが将来役に立つことは少なからずあります。

つづく