スタッフBLOG

おはようございます。本日の当番、プログラマーのH.Kです。


前回ブログでPICマイコンのお話をしていましたが今回はクールダウンして、プログラムのデバッグについて触れたいと思います。

システム設計思想にあるエピソードとして航空業界の2大航空機メーカーであるエアバスとボーイングのテスト方法がどれだけ異なっているかというお話しがあります。

現在もこのような検証が行われているかは不明ですが、エアバスのシステム検証は、機能設計モデル単位で検証を行い、プログラムの動作保証を証明しますが、ボーイングは実機から膨大なテストケースを用いて人海戦術的に実地する手法をとっています。

ゲームプログラムでは、多様な状況の中、多数の入力組み合わせがあるのでボーイング形式のように全ての組み合わせを試みることは実質不可能です。そのため、膨大な機能をモデル単位に分けて検証を行うエアバス形式を取り入れることが多いようです。

どちらの形式も一長一短ありますので、状況によって対応方法を選ぶ必要はありますが、まずバグ報告が上がってきた場合、新米プログラマーが行いがちなのが直観で該当するソースをデバッグしたり修正を加えたりしてしまうことです。運が良ければバグ修正ができるのですが、多角的な要素をもったバグの場合、全く別の箇所が原因だったこともあります。

バグ修正を行う前にやっておくべきこととしてバグの再現手順を確立しておくことが必要になります。

バグの再現手順を確立しておけば、バグ修正できたことを証明するための材料にもなります。

バグの再現は、バグ報告からどのようにすれば再現できるか仮説と検証を繰り返します。複数の仮説を立て、その仮説が原因でないことを検証し、徐々に限定されて最後に残った結果がバグの特定に繋がるわけです。


デバッグスキルは、どれだけバグに遭遇してきたか、原因箇所の当たりや直観力はそういった経験によるところが大きいため、場数を踏むほど蓄積されていきますので、多種多様なバグを経験し、デバッグスキルを向上していければと思います。