https://gist.github.com/teramotodaiki/efac6b29a1b063639661ed55e9e5b9fe/revisions

上のコードは迷路を自動生成するアルゴリズムである。

今回の問題は、この迷路生成の計算が終わらないということから始まった。原因はすでに判明しているが、revisionsの一番古いコードをhackforplayに貼り付けるとそれが確認出来る（ブラウザのタブがクラッシュするので、試すのはおすすめしない）。

無限ループから抜け出そう

このアルゴリズムには、十数個のwhile文が使われている。まずは、このうちのどれかが無限ループになっている、という仮説を立てた。どのループが原因になっているのかを調べるために、まずは怪しそうなループを全て「繰り返さないループ」に差し替えることにしよう。

ここで紹介することは、Gistの２つ目の更新に実際のコードがある。僕のつたない日本語よりもJavaScriptが読みやすいという方は、ぜひそちらをご覧いただきたい。

例えば、

do{ ... } while (count == 1000); 

という繰り返しのコードを 

do { ... } while (count == 1000 && false); 

にすることで、「繰り返さないループ」に差し替えることができる。

ここでひとつ工夫を加える。falseをそのまま付けるのではなく、 __stopper という関数にして、関数の結果として false を返す（returnする）ようにするのである。わざわざ関数を作る利点は２つある。

１．どこで使われたか分かるようにすること

２．true/false （ループさせる/させない）を切り替えられるようにすること

どこで使われたか分かるように、とは、一体どういうことだろうか。引数に適当な数字を入れてみると理解がしやすいかも知れない。先ほどの例はこうなる。

do { ... } while (count == 1000 && __stopper(1));

1というのは仮に入れた数字で、その他の条件式にはそれぞれ違った数字を入れておく。2, 3, ...とナンバリングしていけば分かりやすいだろう。

true/false を切り替えるには、return する値を変えてやれば良い。重要なのは、いつループさせていつ止めるかだが、それには色々な方法がある。ここでは時間を使った切り替えを用いることにする。

まずコードだ。

var __beginTime = new Date().getTime();
var __stopper = function (id) {

    var elapsed = new Date().getTime() - __beginTime;
    return elapsed < 1000;

};

解説すると、最初の行でゲームが始まったときの時間を残している。そして __stopper が使われたときの時間と比較している。

1000 という数字は例で、もしあなたの脳でシュミレートするのであれば、まずは 0 から始めてみると良い。0 では全ての場合で __stopper は false を返す。つまり全くループしない。1000 は 1000ミリ秒、つまり１秒のことなので、ゲームが開始されてから１秒経過するまでは __stopper は true を返す。つまり、この数字はループを止める時間を表している。

（__stopper はストッパーと読むのだが、 true の時は進ませて false の時はストップさせるので、むしろ __repeater かも知れない。こちらの話だ）

ひとまず、0 に設定してみた。するとどうだろう。うんともすんとも言わなかった迷路生成アルゴリズムが、動き出したのだ！（治ったわけではない、仕事を減らしただけだ）

これは何もすごいことをしたのではない。元々のアルゴリズムが良くできていたのである。では、どうしてさっきまでは動かなかったのだろうか？

次の章では、__stopper を使った原因究明のテクニックに迫る。

どこが「無限」の始まりだった？

無限ループに陥っている箇所を知るには、地道にループの回数を１回、２回と数えていくのが効果的だ。無限大という数字は当然数えられないが、他と比べてあまりにも大きいということはわかる。

var __beginTime = new Date().getTime();
var __dump = new Array(15).fill(0);
var __stopper = function (id) {

    var elapsed = new Date().getTime() - __beginTime;
    __dump[id] ++;
    return elapsed < 1000;

};
game.on('load', function () {
    console.log(__dump.join('\n'));
});

__stopper に、ループを数えるための処理を追加した。 __dump は 15 の長さを持つ配列であり、一つ一つの要素がそれぞれの __stopper に対応している。 id には 0〜14 の数字が入るというわけだ。

__dump[id] ++;

という箇所で、要素の数字を１増やしている。これは __stopper が呼び出された回数なので、つまりループの回数と同じになるはずである。

（ && には短絡評価という特性があり、必ずしもループの度に __stopper が呼び出されるとは限らないのだが、今回は気にしない）

そして最後にそれを出力している。console.log はブラウザに備わっている開発者ツールというのを開くと確認できる。次のような結果が得られた。

0
33895
265
795
5232
36233
0
20
2003
134192
132
132
70
6
3

ちゃんと15個ある。そして、ループの深い部分（ループの中のループ）ほど数字が大きくなっていることもわかる（詳しくはGist参照）。

この中で最もループ回数が多いのは、134192回で9番だ。これが無限ループの元だろうか？−−実は、そうではない。本当の原因は、制限時間（1秒）のせいで隠れてしまっている。

ここからは実にコンピュータらしいやり方だ。数字を少しずつ増やしながらループ回数を数え、限界を探っていく。下に、結果のグラフを示す。

文字が小さくて申し訳ない。しかし結果は歴然である。グラフは右側に行くほど上限（ループを止める）時間が長くなり、縦軸はループ回数を表す。500ミリ秒くらいまでは拮抗しているが、その後は 13 だけが伸びている。

原因はどうやら13番にあるらしい。

平均にはあまり意味はないが、あえて平均するとこうなる。

13番だけが長い。ちなみに14番にも問題はあったのだが、13番で時間を使い切ってしまってしまうので、14番は一度も繰り返されなかった。

ここまで長い時間をかけたが、無限ループに陥っている箇所が判明した。

人間は過ちを犯すもの。だからデバッグをする

ここまででわかったことは、 13番のループはたくさん繰り返しているという、ただそれだけの事実である。

無限ループになってしまう原因はまた別にあるし、それもまたデバッグして原因を調べるしかない。原因が13番だけにあるとも限らない。ただちょっと遅いだけで、別のパソコンで動かしたら動いてしまう可能性だってある。

バグの原因なんて、99％はくだらない理由だ。スペルミスとか、コピペミスとか、== と === の違いとか、原因さえわかればすぐ治せてしまうことばかりだ。それなのに、原因を調べるには膨大な時間を要することもある。

デバッグを不毛に感じて、諦めてゼロから作り直すこともできる。それでも問題は解決するかも知れない。しかし、それでは人がデバッグをする本当の目的は達成されない。

我々は自らの過ちに気付くためにデバッグをするのである。

ちょっとした出来心で === を == と書いてしまっていた、その事実を認め、反省し、

「これからは === に統一しよう！」

そう自らの心に誓うまでがデバッグである。

もし自分を顧みることが出来なければ、あなたは一生 === と == を意図せず混同するコーディングライフを送ることになるだろう。職業プログラマでなければいい？デザイナや企画職なら許される？ハッ、そんなことを思っている人間は、何をしてもツメが甘いままだ！

自分の愚かさを認められない人間には、コンピュータも人間も扱えない。

デバッグの辛さから逃げ続けることはできない。あなたも幾度となく苦しむこととなるだろう。しかし、忘れないでほしい。この世に原因不明のバグはない。あなたがコンピュータと真摯に向き合い、デバッグをし続ける限り、いつかは光が射す時が来る。そんな時は、脳内でレベルアップのSEを流してあげよう。強いバグを倒した経験値は、はぐれメタル級に高いのだ。