特にまだ若い開発者によく読んで身につけて欲しい
0
内藤時浩 @tokihiro_naito

デバッグについて内藤の考えを述べます。デバッグは報告、検討、修正、確認のフェーズがあります。報告はデバッグの結果見つかった不具合や疑問などを、所定のルールに則り、開発側に連絡します。必要な情報としては、バージョン、発生箇所、問題点、発生頻度(再現性)、致命度(優先度)が必要です。

2016-10-27 13:46:58
内藤時浩 @tokihiro_naito

バージョンは既に開発側では修正済の可能性があるため、その切り分けのために必要となります。発生箇所は、ステージであるとか、選択キャラであるとか、機能であるとか、そのような客観的な場所を示します。問題点とはそのバグにより何が問題となっているのかを示します。

2016-10-27 13:47:03
内藤時浩 @tokihiro_naito

発生頻度は毎回なのか、十数回に一度なのか、数週間に一度なのか。また、特定の操作により必ず発生するのかを示します。厄介なのが数週間に一度しか発生しない類のものです。発生頻度が低そうに見えますが、製品ともなると、数千数万のプレーの中での発生頻度となりますので、これは高頻度扱いです。

2016-10-27 13:47:13
内藤時浩 @tokihiro_naito

致命度はバグの深刻度です。発生しても笑って許せるレベルのものから、怒り心頭レベルまで様々です。通常、ゲームが進行不可になるものを[S]、ゲームの進行に大きく関わるものを[A]、ゲームは進行するが問題となるのを[B]、要望レベルや面倒くさいだけが[C]と区分しています。

2016-10-27 13:47:18
内藤時浩 @tokihiro_naito

バグの報告は客観的事実だけを元にする必要があります。以前某ゲームでありましたが、「タッチパネルのノイズが酷い」はバグ報告としては不適切です。それはプログラマが確認する事であり、報告者側からは現時点では推察にすぎないためです。客観的事象に沿って報告が必要です。

2016-10-27 13:47:23
内藤時浩 @tokihiro_naito

また、バグの根っこが一緒だったとしても、機能別に別の現象として発生している場合は、別件として報告を行います。これは、バグ修正後に全ての異常動作が修正されたか否かを判定するためです。また、バグの根っこが同じかどうかを判断するのもプログラマです。報告者の仕事ではありません。

2016-10-27 13:47:28
内藤時浩 @tokihiro_naito

バグ報告を受けたプログラマは、最初にそのバグを自分の開発環境で再現させる事から始めます。再現させた結果、内部的に何が起こっているのかを検証します。その検証結果から、修正すべき方策を検討します。

2016-10-27 13:47:33
内藤時浩 @tokihiro_naito

タッチパネルのノイズ問題を例に取ります。現在の仕様そのままで進めるのであれば、リイズの除去を修正方法として検討します。ですが、ノイズの除去ができない、または自分の環境では再現できない場合はどうすればよいのでしょうか。この場合は、ノイズが起こる前提で、別の仕様を考える事も必要です。

2016-10-27 13:47:38
内藤時浩 @tokihiro_naito

スワイプの移動であれば、移動判定となる移動量をより大きくするとか、その移動量を設定できるようにするとか、外部ジョイパッド対応とするとか、自キャラの周囲のタッチ方向で移動方向を決めるとか、方法はいくらでもあります。また、この移動が視認化できるデバッグ機能追加も必要かもしれません。

2016-10-27 13:47:43
内藤時浩 @tokihiro_naito

長押し待機であれば、先の移動量の1/2は同じ位置とみなすとか、さらに待機専用ボタンを用意するとか、ボリュームキーを待機ボタンとして割り当てるとか、指2本でのタッチを長押し待機と同等とみなすとか、こちらも方法はいくらでもあります。

2016-10-27 13:47:48
内藤時浩 @tokihiro_naito

問題が同じであっても、解決方法は同じではない点が重要です。これは要望事項でも同じです。バグと称して要望が入ることがありますが、どうしてそのような要望が出ているのかを考える必要があります。その結果、要望通りではない解決方法を提示する事も多々あるわけです。

2016-10-27 13:47:53
内藤時浩 @tokihiro_naito

修正が完了したら、然るべきタイミングでバージョンを更新の上、再度修正が正しく行われたかどうかを依頼します。この確認では、以前の症状が同様に発生するかを確認します。その結果、問題の解決となっていた場合は[完了]、問題が残っていた場合は、その理由などを添えて[再発]として戻します。

2016-10-27 13:47:58
内藤時浩 @tokihiro_naito

昔はバグ管理はテキストベースで行っていましたが、最近はエクセルであるとか、専用のツールであるとか、汎用的な更新管理ツール(SVNやRedmine等)を使う事も多いです。この辺りは開発規模により、それ相応の仕組みで管理されています。デバッグについては以上です。参考になれば幸いです。

2016-10-27 13:48:02
内藤時浩 @tokihiro_naito

長文、大変失礼しました。結構まとめるの大変でした(笑)

2016-10-27 13:53:13
内藤時浩 @tokihiro_naito

そうそう、バグ報告と要望は別扱いにせよと長年私も言い続けていますが、結論から言うと諦めてます(苦笑)。なので、振り分けは開発者サイドで行うのがよろしいかと思います。まれに報告者が要望と思ってたのが実は意図しないバグの結果という事もありましたので。

2016-10-27 15:05:23