こんにちは、CureAppの新卒1年目、@imoansです。

プログラミングを学び始めた学生時代の私は前回の記事のように成長し、ついにCureAppでバイトできることになりました。
そこからさらに深いJavaScriptの世界にはまっていくことになります。

放り込まれたのは、箱庭だった

githubのレポジトリをcloneし、最初の仕事が始まりました。
とりあえずREADMEを読みつつ聞きつつで環境構築。そして、「ここをいじると作業できるはずだから」と教えられ、簡易なタスクをこなしていきました。

もとからあるコードを見よう見まねで継ぎ足せば、とりあえず実装ができていきます。
テストも、とりあえずdescribeとitを書けば、何やら意図通りに動きます。コードを書き換えるとその都度watchが走って、すぐさま何やらが書き換わります。

当時は、環境のありがたさよりも、業務をこなせる自分の成長に喜びを噛みしめていました。

箱入り娘の弊害

環境が作れない

業務に慣れ、gitやshellと格闘すればなんとか仕事はこなせるとわかった私。趣味でも同じような技術で遊ぼうと試みます。

とりあえず色々と設定ファイルを用意しなければ。
package.jsonとか、Gruntfile.coffeeとか、.gitignoreとか...。
ディレクトリ構成もなんとなく似せたほうがいいよな、srcとかspecとか?

しかし、当時の私はそれぞれの設定がどういう意図で書かれているのかを理解できていませんでした。
どこが自分にとって必要なのか分からず、構築段階で挫折。

とりあえず環境はいいから、普段通り書いてみるも、Google Chromeのブラウザは、

Uncaught ReferenceError: require is not defined(...)

とか言ってきました。
今考えたら当たり前なんですが、怒られて初めて、browerifyは魔法の杖なんだなぁと気づくことになりました。

「browserifyがなかった時代、ファイル間での変数共有ってどう実現していたの？」
「え、globalに変数ぶらさげてたんだよ。」
「えええええええええ」

旧石器時代を偲びました。
このように、JSを書くなら環境構築の庭を作ることが大事であることを実感し、
そのためには結構な知識がいることがわかりました。

戦いの歴史を知らない

他にも、JavaScriptがいかに混沌から整備されてきたのか、ということに無頓着だったエピソードがあります。それはPromiseです。

プログラミングを始めてから、非同期処理にはPromiseを使うように、と叩き込まれていましたが、なぜPromiseが嬉しいのかはあまり分かっていませんでした。
説明記事で比較される「コールバック地獄」って、まあちょっと汚くなるよね、ぐらいの認識でした。

ある日、自分の使っているライブラリのバグっぽい挙動に悩まされ、ソースコードを見ることになりました。

密林のようなソースコードのなかで現れたのは、200行の1関数の中に何重にもネストされたコールバック関数でした。
コールバック全体をtry / catch で包み込むといったことができないので、エラー制御フローは追えたものではありませんでした。

この一件を経て、ネストも深くならず、どこでエラーが起きようとcatchできるPromiseは偉大なんだなあと気づくことになりました。
戦いの歴史を知らないままベストプラクティスだけを使っていると、技術のありがたみに気づくことができません。

次世代の足音

しかし、その「ベストプラクティス」というのも、永遠ではないのでした。
やっとgulp/browserify/CoffeeScriptの環境を覚えてホッとした私。
そのうち新しいプロジェクトが始まることに。

新プロジェクトは babel/React/webpack でいくぞ！

なん....だと......

thisやnullのつらみを隠蔽してくれたらしいCoffeeScriptも、もうベストプラクティスではないのか...。ReactってJSのなかにタグあるのになんで許されているの？Reactが解決したかった問題って、まだ実感できてないんですけど。
あとbrowserifyはどうしてダメなの?
Promiseがさらに隠蔽されるasync / await ってなんやねん!!!!

次世代の足音は、またもや新たな環境構築を強いるものでした。
このサイクルの速さに振り回されるばかりの私でした。

続く...

この時期を振り返って

環境がある理由が、後から分かる

振り返ると、初級者のうちから整った環境で作業したほうが、即戦力になったといえるでしょう。
フルスクラッチで色々調べて構築するよりも、学習効率はよいはずです。
ただし、どうしてこの環境が生まれたのか、どうしてこの環境がよいのか、を知るためには
自分で環境との接点に触れて、発見していくことが必要です。

「browserify、ありがたかったんだ」というのは、JavaScriptを昔からやっていた方々からすれば当然のことのようですが、私にとっては新鮮でした。
昔の辛さを記事やレガシーコードで知りながら、今の技術の良さを心から理解していくのが、今JSを始め(て仕事にす)る初級者に求められるのかなと思いました。

環境を自分でつくれるまでは長い道のり

Reactを触ってみよう、となったとき、レシピ通りに環境構築を進めれば初級者でもHello Worldまでは実現できる時代です。
けれど「このレシピ、バージョン古いから動かない」とか「このスタックがベストなんだっけ」という問題は、初級者にはハードルが高いです。
業務で技術選定をしている経験豊富なエンジニアに相談したりして、徐々に自分でも技術選定できるようになりたいです。

次回は、実際にbabel/React/webpack/flow/eslintを触って荒波に揉まれるJS初級者の様子を書いていきたいと思います。お楽しみに！

明日のCureApp Advent Calendarは@janus_welさんです！