と言ってもファミコンの『テニス』から続く由緒正しいテニスゲームではなく、画面の両端に板（パドル）が出るテニスである。画面中央で動く障害物の数によって、サッカーになったりバレーになったりするあのテニスゲームだ。
あんなゲームでバグが出せるの？ と思うだろう。実際、あのゲームはプログラム自体もシンプルで、そうそうバグが潜む余地はない。しかし、そういうシンプルなプログラムでバグを出すのはものすごく燃えるのだ。堅いガードを突破する喜びとでもいうのだろうか。ガード破りといえばハッキングを連想する人もいるだろう。それは限りなくグレーな行為だが、デバッグならばいくらでも突破してよいのだ。これが燃えないはずがない。
さて、あなたがテニスゲームをデバッグすることになった場合、まず、何から手をつけるべきだろうか。プログラムの確認？ 仕様書の理解？ いきなり現物をさわる？ どれも面白いのだが、私はプログラムの更新履歴を見る。プログラマーがどんなプログラムを入れ込み、どんなバグを直してきたか、それでわかるからだ。
特に面白いのは「どんなバグを直したか」。過去に出したバグを直したという記録だが、直しの甘いプログラマーだと、直しもれを残してくれるのだ。
複数の箇所を直さなければならないのに、一ヶ所しか直していない。
直してはいけないところまで直してしまい、かえってバグが悪化する。
直したのだがプログラムに反映されていない。
プログラムの更新履歴自体が間違っていた。
などなど、バリエーションは様々だ。プログラマーの人となりをよく知っている場合、その人がやらかしがちなミスを先読みしてデバッグするくらいである。これをやると大変にプログラマーから嫌われるのだが、デバッガーはプログラマーから嫌われてなんぼの商売。どんどん嫌われるようにしよう。
さて、最新の更新履歴を見ると、「パドルの両端にボールを当てた場合、ボールがパドルを通過するバグを直しました」と書いてある。パドルには厚みがあるから、その厚みの部分にボールを当てるとすりぬけてしまうバグを対処したのだろう。元のバグレポートを見ると、「パドルを動かしている時に発生した」とある。そこで、パドルを動かしつつボールを受け、さらにパドルを動かさずにボールを受けてみたりした。が、どちらの場合もきちんとボールを跳ね返すようになっていた。
これは直ったかな？ とあなたは考える。そこで、いったん確認をやめ、今度は別の更新履歴を見る。と、「パドルの後ろ側に消える安全地帯をつけました」とある。消える安全地帯とは、パドルの後ろ側にある、“ボールが当たると、ボールを跳ね返した後に消えてしまう”板状のものである。ブロック崩しにも出てくる、ボールを落としても一回は大丈夫なバリアみたいなものを想像してもらうとわかりやすい。
それを見ていて、あなたはふと気がつく。
「もしかして！」
そう、「消える安全地帯にボールを跳ね返させ、その跳ね返ってきたボールをパドルの両端に当てる」作戦だ。これまでのテニスゲームは、“正面からボールが飛んでくる”のを跳ね返していた。当然、パドルの後ろ側から飛んできたボールを跳ね返す、そういう処理は組み込まれていなかったのだ。
ちなみに、あなたの作戦は成功した。後ろから跳ね返ってきたボールにパドルの両端を当てる操作は難しく、プログラマーが試せなかったからである。
かくして、更新履歴に対してレポートを提出したあなたは、プログラマーからこう言われてしまうのだ。
「またシビアなタイミングのバグを出してきましたねえ。全く再現できませんよ……」
