読者です 読者をやめる 読者になる 読者になる

timakin.log

╭( ・ㅂ・)و ̑̑

新しい技術を恐る恐る使う。ES6とか。

プログラミング エンジニア テクノロジー JavaScript ES6 React

技術的経験の学びの整理方法

Serverside ES6というタイトルでLTをした。

www.slideshare.net

近頃外部に情報を発信するときはポエムが多く、

どうしても技術的な色が薄かった。

今回はちゃんと技術寄りのトピックを扱ったが、エモさが足りなかった。

技術的な学びよりも、よりポエムっぽい

内容のほうが、より広く学びが共有できる反面、

専門分野での自分の経験値を高くし、

自分より上の専門家の方々からの目線が、

「本当にこいつちゃんとやってんのか?」という

懐疑的なものにならないように、

バランスをとるのは非常に難しい。

ただ一つ分かることとして、まとまったコードを書いた後に、

  1. 自分がもともとどういうモチベーションでその技術に取りかかり
  2. その過程でどういう感情を持ったのか
  3. 結果どういう技術を手にいれたのか

という整理の仕方をして、

配分を2:4:4くらいで整理すればいいのだろうと思い始めた。

LTのほうでは、前述の通り感情面の話が薄かったので、このブログはその補足。

この技術を扱ったモチベーション

結論から書くと、フロントエンドからの逃げだ。

巷で流行りのReact.jsを触っていて、

コンポーネントにバンバンAPI fetch用の関数とかを詰め込んだら、

「責任が分割できてないし、密結合になってるから

これはコンポーネントじゃない」というお叱りを受けたことがある。

それを皮切りに、Fluxデザインパターンを学ぼうと思い、

スター数と成長速度からしてReduxだろうと思い、Reduxを触った。

ただ、途中でreact-routerと一緒に使い始めたあたりから、

stateがどこか無限の宇宙に消えてしまい観測不可能になったので、

もっと軽めのものでトライしたほうが速そうだと思い、Facebookのflux実装を使っていた。

が、徐々に書いていくにつれ、

  • 自分が作りたいと思うアプリがこの技術を必要としていないこと

  • コード量、かけた時間というコストに対して、得られるものが自分にとって大きくなかったこと

  • 技術自体の流行り廃りが速く、自分の手に余るものだったこと

という課題が表面化してきて、フロントエンドフレームワーク

最前線のキラキラした世界(捉えようによっては逆)から、戦線離脱しなくてはいけなかった。

技術的自己顕示欲

これは自分のやりたいことと技術を結びつけるという

当たり前の手段選択を、「新しい、流行の技術を触ったら、なんだかかっこいいぞ」という

顕示欲に目が眩んで、見事に玉砕したということに他ならない。

自分のコントロール下に置けないファットまたは

流行り廃りの激しいライブラリ・フレームワークを使うことは、

まるでポケモンでジムリーダー3人目を倒した段階で、

友達からレベル100のポケモンを譲り受けて、

結局いうことを聞いてくれないような、手にあまる事態にしかならない。

(フロントエンド界隈の人が自己顕示欲が高いとかいう話ではない。

むしろ流れを追いつつも基礎ができてないと

常にしがみ付くのが難しいはずなので、純粋に敬意しかない。)

ほぼ100%、その課題にぶつかるにもかかわらず、

技術的な顕示欲に目が眩む問題とどう戦うか、

ということを考えるいいきっかけになると思って、

一旦フロントエンドの話を置いて、サーバーサイドで「安全地帯」からES6を学ぼうと思った。

ES6をサーバーサイドで使う

これは正解だったと思う。

というのも、フレームワークという周辺部分にとらわれず、

純粋にES6のシンタックスの便利さを実感する機会になったからだ。

expressのソースコードを大部分ES6に置き換えたが、

特にメリットを実感したのはモデル部分だった。

Arrow Functionとunderscoreの合わせ技のおかげでビジネスロジック

(見た目上)簡潔に書けるのと、コールバック関数への抵抗感を和らげてくれた。

何よりClassesがあることで、自分は「モデルオブジェクト」を扱っているのだという

感覚を持ちながら、迷うことなくコードが書き進められた。

慎重にドキュメントを読む

今回はドキュメントは公式に近いソースを読むように努めていた。

あるいはソースコードに当たること。

ここでいうと、MDNやそれこそES6のドキュメントだと思う。

もちろんこれはドキュメントが少ないのもあるが、

フロントエンド由来のサンプルコード自体はゴロゴロ転がっていたので、

実際にはサンプルには事欠かなかった。

ただ、それらすべてを一旦置いといて、

できるだけ公式の範囲におさめるのは非常に難しい。

公式のドキュメントが平易なことはそうそうない。

シンタックスや機能の背景についてある程度知ってる周辺記事の方がよっぽど助けになる。

一方で、結局戻ってくる先として公式ドキュメントを使わないと、

こういう鮮度の高い技術は誤解を招く。

例えば今回だと、Generatorsで結構困ったのが、同期的に書けるという記述が多く、

最初のうちはPromiseみたく非同期処理をうまく記述できるものかと思っていた。

実はイテレーター的なものだというのを、ドキュメントをちゃんと読むまではっきりわからなかった。

この問題は最初から公式に当たれば解決するかというと、多分そうではない。

公式ドキュメントは一番わかってる人によるまとめであっても、

それが必ずしも一番わかりやすいとは限らない。

結局は自分の経験値を公式ドキュメントと照らし合わせて、

自分の言葉で言語化する作業が必要だ。

そういう意味で、「手を動かすしかない」ように思えた。

新しい技術に恐る恐る触る

タイトルに補足をすると、ES6自体は、

「その界隈からすれば」別に新しくはないと思う。

でも一旦その界隈から離れてみると、

だいぶ新しい技術として認知されてるようだった。

(まあこの際、ES6は記法であって技術ではないかもしれないが)

  • 安定版が出ている事

  • 一定期間メンテナンスが持続する事

  • 実際に課題を解決をする事

  • 変化が止まっていない事

  • 広く「まあ新しいよね」という印象を持たれている事

の5つの条件を満たすような技術はレア度が高い。

だがそういう技術でない限り、別段触れなくてもいいのだろうと思い始めた。

低レイヤーだったり、設計思想的なところを勉強するのに時間をかけつつ、

いざ上記の条件を満たしてると思われる技術が出た時に飛び付けるように、

情報感度を高く保ち続けたい。

というか今は飛び付けるほどのベース知識が足りてないから、

技術的自己顕示欲を捨てて、できるだけ堅実に学ぶようにしないと今後が辛い。