WEBフロントエンドの学習の仕方

2019年10月08日にサポーターズCoLabにて発表した内容になります。

以下の内容を大題として発表しました。

1. 新しい情報を消化するまでのルーチン
2. 情報収集の巡回と消化に必要な知識
3. WEBフロントエンドの背景知識（ざっくり版）

中盤から後半に進むほど難易度が徐々に難易度が高くなっていますが、WEBフロントエンドの学習を進めて行きたい方で、次に何をやるべきかわからない場合の指針として閲覧いただければ幸いです。

・イベントURL：https://supporterzcolab.com/event/956/

Transcript

1. WEBフロントエンドの 学習の仕方 1 2019/10/08 【生配信】フロントエンドの学習の仕方【サポーターズ CoLab】 https://supporterzcolab.com/event/956/
2. 2 姫野 滉盛 所属 • 株式会社ドワンゴ SNS • GitHub@Himenon • Twitter@himenoglyph 自己紹介
3. 3 1. 新しい情報を消化するまでのルーチン 2. 情報収集の巡回と消化に必要な知識 3. WEBフロントエンドの背景知識（ざっくり版） アジェンダ
4. 4 ◉ スライドを公開しているので、先読みOK ◉ 気になるところはコメントをください ◦ 可能な範囲で応えます ◉ 誤字脱字や間違っている場所があれば遠慮なく指摘してください お願い
5. ◉ WEBフロントエンド初心者 ◉ 学習方法がよくわからない・途中挫折しがち ◉ 「ドメイン駆動開発」という言葉に馴染みない ※発表したところ、Feedbackの中で難しいというご意見をいただきました。WEBフロントエンドという職種があるような チーム構成だと必要になってくるような知識として記述してしまっているため、バックエンドとフロントエンドの結合度が 高い状況を想定し損ねています。フロントエンドの柔軟性を取り入れていきたいというような状況に置かれた場合の一 つの指針として中盤以降は読みすすめると良いかもしれません。 5 本スライドの対象
6. 新しい情報を 消化するまでのルーチン 自分自身の行動の振り返り 6
7. 1. GitHubを開く 2. 気になるRepositoryがある 3. READMEを見る a. → 面白そうだったら★ 4. ★動かす a. → 面白かったら★ 7 新しい情報を消化するまでのルーチン GitHubで発見パターン
8. GitHubのライブラリ巡回パターン 1. GitHubを開く 2. JavaScript系のライブラリの場合、package.jsonのdependencies, devDependenciesを見る 3. 知らないライブラリを片っ端から開く 4. npmjsで利用数、Dependentsを見て、利用数の多いものから調べていく 5. 作者をフォローする a. GitHubのタイムラインが充実する 8 新しい情報を消化するまでのルーチン
9. 1. Twitterを開く 2. 良さそうな情報を発見する a. 有名なライブラリの作者やメンテナーの発信 3. だいたいGitHubへ飛ぶ 9 新しい情報を消化するまでのルーチン Twitter巡回パターン
10. まとめ • 自分のネットサーフィンの巡回経路に新鮮な情報が取り入れられるように しておく。 • 有益な情報源を埋もれさせないようにする。 • 見つけたときに手を動かすようにする。 10
11. 情報収集の巡回と消化に 必要な知識 11
12. 12 フロントエンドの学習の指針 • WEB DEVELOPER ROADMAP ◦ https://github.com/kamranahmedse/developer-roadmap ◦ https://roadmap.sh/ 何をどこで使うのかを具体的 に紹介していきます 情報収集の巡回と消化に必要な知識
13. アプリケーション開発の練習をするとき 開発設計の学習は多くの挫折ポイントがあるる 1. テーマを決める（挫折ポイント1） 2. 環境構築をする（挫折ポイント2） 3. 設計・開発（挫折ポイント3） 4. バグが取れない（挫折ポイント4） 5. デプロイする（挫折ポイント5） 13 情報収集の巡回と消化に必要な知識
14. アプリケーション開発の練習をするとき 開発設計の学習は多くの挫折ポイントがあるる 1. テーマを決める（挫折ポイント1） 2. 環境構築をする（挫折ポイント2） 3. 設計・開発（挫折ポイント3） 4. バグが取れない（挫折ポイント4） 5. デプロイする（挫折ポイント5） 14 情報収集の巡回と消化に必要な知識
15. 私の解決方法： テンプレートジェネレーター（ボイラープレート） もしくはcreateapp系のCLIを利用する 理由： • 設計・開発に時間をかけたい • 環境構築については、相談相手がいること or 十分な検証時間が必要。 挫折しないような環境構築を最初にしておくことがキモ 15 情報収集の巡回と消化に必要な知識 - 環境構築をする
16. フロントエンドフレームワークを利用する場合 • React ◦ create-react-app（https://github.com/facebook/create-react-app） • Vue ◦ Vue-cli • Angular ◦ Angular-cli テンプレートジェネレーター CLIにバンドルされているタイプ 16 情報収集の巡回と消化に必要な知識 - 環境構築をする
17. • 自作ジェネレーターを作る場合（玄人向け） 生成時にインタラクティブにパラメーターを調整できる ◦ yeoman（JavaScript製） ▪ https://yeoman.io/ ◦ cookiecutter（Python製 / 玄人向け） ▪ https://github.com/cookiecutter/cookiecutter • Github Template（初心者にも優しい） ◦ https://help.github.com/ja/articles/creating-a-repository-from-a-te mplate テンプレートジェネレーター 自由度が高いタイプ 17 情報収集の巡回と消化に必要な知識 - 環境構築をする
18. • メンテナンス頻度 ◦ 主にpackage.jsonのdependenciesを見るとよい ◦ GitHubを見れば最終更新日があるので、それを観察 • 公式が出しているものほどメンテナンスされている ◦ スターが付いていても老朽化しているものが多いので注意 テンプレートジェネレーターを 使うときに気をつけること 18 情報収集の巡回と消化に必要な知識 - 環境構築をする
19. テンプレートジェネレーターを使ったほうが良いか？ （個人的意見） • 環境構築に興味が湧くまでジェネレーターを使うほうが モチベーションが保てるため。 • 寄り道をすると多くの知識は得られるが、知識の点を線でつなげるのはと ても時間がかかるため。 19 情報収集の巡回と消化に必要な知識 - 環境構築をする
20. “ ネットワーク環境が良ければ ジェネレーターのDEMO 20
21. アプリケーション開発の練習をするとき 開発設計の学習は多くの挫折ポイントがあるる 1. テーマを決める（挫折ポイント1） 2. 環境構築をする（挫折ポイント2） 3. 設計・開発（挫折ポイント3） 4. バグが取れない（挫折ポイント4） 5. デプロイする（挫折ポイント5） 21 情報収集の巡回と消化に必要な知識
22. テーマを決める 何もテーマが思いつかない場合は以下の2つを題材につくる • カウントアプリ ◦ Hello World気分で作る • TODOリスト ◦ 応用を利かせて作る ◦ http://todomvc.com/ 迷ったらこれ 22 情報収集の巡回と消化に必要な知識 - テーマを決める
23. アプリケーション開発の練習をするとき 開発設計の学習は多くの挫折ポイントがあるる 1. テーマを決める（挫折ポイント1） 2. 環境構築をする（挫折ポイント2） 3. 設計・開発（挫折ポイント3） 4. バグが取れない（挫折ポイント4） 5. デプロイする（挫折ポイント5） 23 情報収集の巡回と消化に必要な知識
24. • デザインパターン ◦ https://www.techscore.com/tech/DesignPattern/index.html/ • アーキテクチャ ◦ アプリケーション系 ▪ ドメイン駆動開発（ユビキタス言語, DI, DIP, CQS, CQRS, ...etc ) ◦ インフラ系（Backend領域） ▪ Continuous Integration（CI）/ Continuous Delivery(CD) ▪ Websocket / Rest API Why：小手先のテクニックだけではない話がたくさん転がっている為 設計と開発の練習内容 なるべく早く手を出したほうが良いもの 24 情報収集の巡回と消化に必要な知識 - 設計・開発
25. アプリケーション開発の練習をするとき 開発設計の学習は多くの挫折ポイントがあるる 1. テーマを決める（挫折ポイント1） 2. 環境構築をする（挫折ポイント2） 3. 設計・開発（挫折ポイント3） 4. バグが取れない（挫折ポイント4） 5. デプロイする（挫折ポイント5） 25 情報収集の巡回と消化に必要な知識
26. バグが発生してもなかなか解決しない バグの種類によって、バグの特定と対策が可能な状態を目指す • 理解度の問題：同期・非同期処理などの理解がおいつていない ◦ 例）callback, Promise, async/await • 技術の問題：テストが無い ◦ テストを自然に書ける環境がないなど • 複雑度の問題：バグの原因が絞り込めない場合 ◦ 責務分離が明確でないアーキテクチャの可能性 ◦ 要件が複雑な場合（現実） 26 情報収集の巡回と消化に必要な知識 - バグ
27. バグが発生してもなかなか解決しない できる範囲で仕組みで解決する • 理解度の問題 ◦ わかるまで調べる（大前提） ◦ わからなければ、Q&Aサイトにわかったところまで質問する • 技術度の問題 ◦ テスト(jest) / 構文チェック(eslint) / 型(typescript) • 複雑度の問題 ◦ アーキテクチャで受け止める（難易度高） ◦ ドキュメントで情報共有など → 後のスライドで掘り下げる 27 情報収集の巡回と消化に必要な知識 - バグ
28. アプリケーション開発の練習をするとき 開発設計の学習は多くの挫折ポイントがあるる 1. テーマを決める（挫折ポイント1） 2. 環境構築をする（挫折ポイント2） 3. 設計・開発（挫折ポイント3） 4. バグが取れない（挫折ポイント4） 5. デプロイする（挫折ポイント5） 28 情報収集の巡回と消化に必要な知識
29. WEBフロントエンドの場合、HTLM/JavaScript/CSSをWEBサーバーにアップ ロードすれば完了します。代表的な例は以下。 • GitHub Pages（https://pages.github.com） • Netlify（https://www.netlify.com） 初めてやる場合や、検証用、コストを掛けたくない場合におすすめ デプロイする 最も簡単な方法 29 情報収集の巡回と消化に必要な知識 - デプロイ
30. デプロイする もっといろいろ試しておきたい人向け 自分でWEBサーバーを立ち上げたい場合 • Nginx / Apacheなどを利用 ◦ GCP/AWS/さくら/ロリポップなどでホスティング ◦ Ansibleなどの構成管理ツールを使ってみる • コンテナでデプロイ ◦ Docker Swarm / k8s ◦ オーケストレーションツールの練習など • CDNにデプロイ ◦ AWS / GCP / Fastlyなど 30 情報収集の巡回と消化に必要な知識 - デプロイ
31. まとめ • 手を動かすまでが短くなるように、ツールを使って楽をすること。 • モチベーション低下を避けるために、相談相手がいない場合や十分な時 間が取れない場合とき、環境構築などの技術的難易度の高いところは後 回しにしておく。 31
32. “ 小休止 質問など 32
33. 検索をかけたときになぜこれを使っているのか？ 何が良いのか？どこへ向かっているのか？を解消したい。 33 WEBフロントエンドの背景知 識（ざっくり版）
34. 34 jQueryと仮想DOM • jQueryはスクレイピング ◦ レンダリングされた目的の DOMを取得し、イベント(onClickなど)をバインドす る ▪ 目的のDOMがレンダリングされていると限らない ▪ DOMの取得 → バインド → 要素の更新 → バインド, etc… を実装する と小規模を超えたあたりからコードが瓦解を始める • 仮想DOM ◦ JavaScript内からDOMを生成する。 ▪ → DOMがあることを保証できる ◦ 生成時にイベント(onClickなど)をバインドする。 ◦ JavaScript内でDOMのライフサイクルを定義できる → JavaScript内でDOMのライフサイクルを手に入れた
35. DOM？ライフサイクル？ • DOM（Document Object Model） ◦ 値（文字列/数値）、スタイルの両方を持つ • DOMのライフサイクル（ざっくり） ◦ DOMは受け取るイベントから、表示を変化させる 35 生成 表示 イベント 更新
36. ライフサイクルをJavaScriptで管理 すると何が良いのか？① • アプリケーションに必要なデータ の流れと、 ユーザーに提供するViewの管理を分離することができる。 右図の例の場合 • アプリケーションに必要なデータ ◦ 氏名の値「hoge fuga」 ◦ 年齢の値「18」 • 上記以外はViewを構成する情報 ◦ フォーム/氏名/年齢 ◦ 枠、サイズなど 36 hoge fuga 18 氏名 年齢 フォーム
37. ライフサイクルをJavaScriptで管理 すると何が良いのか？② ※ここから先はデータと呼ばず、状態（ State）と呼びます。 • フロントエンドが扱う状態のことを Stateと呼ぶことが多い。 状態（State）をDOMから引き剥がして、JavaScriptの中で取り扱うことができた ので、一般に知られているアーキテクチャを用いた状態管理 を行うことができる ようになった。 → 次のページに具体例 37
38. アーキテクチャで対応すること 例：仕様変更 • 氏名、年齢を入力と同時にフォーム下部に「〇〇さん 〇〇歳」と表示するよう にする。 38 hoge fuga 18 氏名 年齢 フォーム hoge fugaさん 18歳 const state = { name: “hoge fuga”, age: 18 }; Stateの参照をそれぞれの DOM に渡すだけで済む
39. “ 39 時間があれば仕様変更を カウントアプリでDEMO
40. アーキテクチャがもたらすもの 40 • 一定の水準を満たした品質をアプリケーションを構築できる。 • ライブラリやフレームワークは非機能要件の多くを最初から提供してくれて いる。 ◦ 例えば今回取り上げたデータの整流機能を予め持っているなど
41. より品質を上げるための方法 • 実際の成長するアプリケーションは、ライブラリやフレームワークが提供す るアーキテクチャでは対応しきれない点が生じる。 • ドメイン（=ソフトウェウア化する対象）に対して深い理解をし、特定の技術 に依存しない設計が必要となってくる。 ◦ → ドメイン駆動開発へつながる • 洗練されたアーキテクチャは誰が書いても、実装方法や実装場所が同じ 様になってくる。 41
42. • React/Vueなどのフレームワークは DOMのライフサイクルをJavaScript中に収め た。 • フレームワークは一定の水準を満たした品質を提供する • ただし、開発的な骨格という位置づけ。 • 仕様変更や新機能実装などの実際の要件に対応するにはドメインを含む設計を 行う必要がある。 まとめ 42
43. 全体のまとめ • 筆者のキャッチアップ方法について紹介した • フロントエンドの学習で躓きそうなポイントについて問題とその解決方法を 紹介した • WEBフロントエンドでメジャーなライブラリらが行っていることについてエッ センスを話した 43
44. “ 44 おわり