フロントエンドの適材適所と、エンジニアは何を学ぶべきか
Kaizen Platform フロントエンドエンジニアの中村です。
現在開発中のプロダクトでは、フロントエンド開発のフレームワークに React + Redux を採用しています。
当初は自分が一人で開発していましたが、チームのRubyエンジニアの皆が次々と React を習得、気がつけばフロントエンドの機能実装も担うようになり、おかげでフロントエンド専門の自分はUIデザインの補佐 & UXの向上へ手が回せるようになりました。
弊社のビジョンは『21世紀の新しい雇用と働き方の創出』ということで、会社の壁を越えた適材適所を目指しているのですが、社内でも「適材適所」が進んでいるというわけです。
畢竟、開発チームの皆さんが仕事しやすいよう、技術基盤の整備に邁進するのですが、新しいツールやライブラリを導入するにも適宜判断が必要になりまして、じゃあ何をどう選ぶかについて意見を持てる & 説明ができることが、チーム開発におけるフロントエンドエンジニアの仕事の一部かなと思う次第です。
そこで、普段どうやって技術選定しているのかについて、近ごろ目にしたライブラリでちょっと気になっている rollup.js を例に、少し掘り下げてみたいと思います。
技術選定の際にやっていること
それは何を解決するのか
React + ES2015 で SPA 開発する場合、何かしらのツールで ES5 にトランスパイルする必要があるため、webpack or Browserify を利用することになります。
最近のWeb SPA 開発だと、JS トランスパイル以外に SCSS もバンドルしたい、ミニファイもしたい、lint も走らせたいなど要件も多岐に渡り、開発環境を作るのに手間がかかります。
その際、Grunt, gulp でワークフローを組んでもよいですが、webpack は JS、CSS その他諸々の面倒を見てくれるので、一度環境を作ってしまえば楽なのがメリットです。
今回の rollup.js は JS のトランスパイルを担当するライブラリのようなので、webpack の全機能を代替するものではなく、むしろ Browserify の代替といった位置付けになりそうです。
現状の何が辛いのか
開発中のプロダクトでは webpack を利用しています。
webpack で特に辛いということも無いのですが、強いて言えば
- 設定やプラグインの思想が独特、’webpack way’ のようなものに乗る必要がある
- プラグインでなんでもできる反面、なんでもできすぎて処理が巨大になりがち
- 出力する bundle.js の容量が増えがち
といったところでしょうか。
自分が気づいていない辛さがまだまだあるかもしれません。
得意なことは?
rollup.js の売りは 「Tree-shaking」だそうで、これは JS をトランスパイルする際、import しているライブラリのうち必要な関数のみをコンパイルしてくれる機能です。
未使用の関数を除去できるため、出力する JS のサイズを小さくすることができます。
また、ES2015 ネイティブで動作するのも特徴で、従来のバンドルツールでは CoffeeScript を一旦 ES5 に変換してからバンドルするところ、rollup.js は何でも ES2015 に変換し、必要に応じて Babel でトランスパイルするとのこと。
これによって Tree-Shaking を可能にしているようです。
現状、Tree-Shaking によるバンドルサイズの縮小は rollup.js の優位性と言えそうです。
ただし、webpack は ver.2 で Tree-shaking に対応する予定があるとのこと。
触ってみる
得意、不得意を調べる際、ドキュメントをざっと読んでいまいちわからないところは実際に触ってみます。
CodePen などを利用すると、ブラウザ上で動作を試せるので、非常に便利です。
幸い rollup.js の場合は公式サイトに playground があったので、すんなり挙動を理解することができました。
苦手なことは?
JS 以外は対応してないので、webpack から乗りかえる場合は別途 CSS などのコンパイル手段を整備する必要があります。
要件にマッチするか
開発中のプロダクトでは全て webpack に任せず、gulp タスクと webpack タスクを併用しているので、JS バンドル部分を rollup.js に置きかえることは問題なさそうです。
ただし React Hot Loader は使えなくなるので、その点は要検討。
手になじむか
コンフィグファイルはシンプルなJS(ES2015)で書けてわかりやすいです。オブジェクトを export する記述は webpack とほぼ同じですね。
import buble from ‘rollup-plugin-buble’;export default {
entry: ‘src/main.js’,
dest: ‘dist/bundle.js’,
format: ‘umd’,
plugins: [ buble() ]
};
他にもっといいものはないのか
ES2015 を ES5 にバンドルするツールでいえば、 webpack, Browserify あたりが候補で、React 界隈のデファクトスタンダードは webpack なので、ここは今回は考慮しなくてよさそうです。
以上を踏まえると、弊社で開発中のシステムに rollup.js を導入するのは、
- 検討の余地あり
- 導入のインパクトはまだそこまで大きくない
- 今後、webpack2 の動向も見すえつつ、リプレイス候補として頭の片隅に置いておく
といった判断に落ちつきそうです。
前提知識の仕入れ方
こんな感じでライブラリの得意・不得意を比較してみると、それを利用するメリット、デメリットを掴むことができます。
とはいえ、今回の場合は前提知識として webpack や Browserify, npm, Grunt, gulp などを知っている必要がありますし、それをいちいち調べるのは面倒ですよね。
「フロントエンドは流行り廃りの流れが早くてついていくの大変、どれを選んでいいのかわからない」
確かにそうだと思います。トレンドの変化は早いし、フレームワークの衰勢も近ごろは1年程度で様変わりしています。
流れの早さは受けいれて泳ぐしかないのですが、いざ何を選ぶかについては、流れていくものを眺めておけば、一定の指針を持つことができます。
ニュースを流し読みしつづける
現状 Web Frontend は JS 一択なので、JS関連のニュースをしばらく眺めていると、メジャーなもの、流行っているもの、注目株、枯れてきたものなどがなんとなく掴めるようになってきます。
コツは、ニュースの中で何度も目にするワードが出てきますので、そのワードの表われ方や記事の内容(紹介記事、チュートリアル、支持・不支持のオピニオン、ベストプラクティスなど)を見て、印象として覚えておくことです(内容は忘れてしまってかまいません)。それを繰り返して印象を積み上げていくと、だんだん現在のメジャーどころやトレンドが見えてきます。
今なら React, Redux, Angular2 (祝リリース)、少し先だと、Rx, BFF, PWA, Web Components あたりでしょうか。
メジャーどころとその対抗馬などが見えてきたら、先程の手順で比較検討してみたり、さらに紹介記事を眺めて要点を掴みます。興味があればソースを読んでみてもいいかもしれません。
メジャーなものがなぜ支持されているのかを掴めればそれが基準になりますので、プロダクトにとって適切なツールはどれなのか、自然と技術選定もしやすくなると思います。
ちなみに自分がウォッチしてるニュースソースは、
あたりになります。
なかでも、国内・海外のフロントエンド関連記事を、日本語のサマリ付きでキュレーションしてお届けしてくれる Frontend Weekly はオススメです。
そんなわけで、Kaizen Platform では共に歩む仲間を募集中です。
我こそは適材である、もしかして自分の適所なんじゃない? と思った方、あなたのご連絡をお待ちしております。
