JavaScript の非同期処理のクセが強いんじゃば

われわれのグループ（ネタのみ提供者含む）は、どういうわけか JavaScript （つか node 案件）に関してガチ仕事レベルで取り組んだものは一人もいない。

いや、簡単なウェブ案件はあるんすよ。

だが、chrome 拡張に手を出すにあたってそれじゃいかんだろうとようやくある程度本格的にプログラミングし始めた。

node 系の隆盛などは知っているし、「ブラウザ以外でも動作するようになって・・・」みたいな歴史的な知識もある。

でも、実際にプログラム組まないとその言語固有のクセなんてわからない。

 

けっこう見落とされがちなのは「JavaScript は非同期処理」というものだろう。

例えば、

---

処理１

処理２

処理３

---

というようなプログラム構造があった時、処理２が重いと先に処理３を実行することがある。
だから、処理２を処理３より前に実行したいときは promise を使いましょう、みたいな教科書にも出てくるよくある話に繋がるわけだが、知識として知っていても実務レベルで身についているかというとそんなことはなく、バグを作るときは作る（笑）。

この前イタい思いをしたのは次のようなケース。

---

コールバック関数１{

promise(

コールバック関数２

処理A

).then{

処理B

}

}

---

こう書くと「コールバック関数２が完了した後に処理Aが走ると思い込んで不具合起こしたんでしょ」と言われそうだが、実際、その通り。

もちろん落ち着いて考えれば、コールバック関数２の処理が重い場合、JavaScript はしれっと処理Aを先に実行してしまうってのはわかる。

大体においてコールバック関数を使うのは思い処理をやらせたいときだから、バグが出るのは当然なのだが、初学者のワイは「promise 使ってるじゃん！コールバック関数２と処理Aが何でこの順序でできないんだよ」と静かに怒りを覚えていた。

ちなみに何でこの不具合に気がついたかといえば、コールバック関数２で値を代入した変数が、処理Aの時点で何度実行しても undefined になっていたから。

慣れてくれば、undifined が出てきた時点で、「ああ、これは実行順序に起因するバグだ」と気が付くのだろうが、習いたての段階ではそうそう気が付かないのだ。

色々と学びの多いプログラミングでやんした。

 

（続く）