フロントエンドにおけるアーキテクチャとの向き合い方

by camcam_lemon

Slide 1

Slide 1 text

フロントエンドにおけるアーキテクチャとの向き合い方 FRONTEND CONFERENCE FUKUOKA2019

Slide 2

Slide 2 text

Name 甲斐田亮一 Twitter @camcam_lemon Company 日本事務器株式会社 Skills TypeScript, React / Figma Occupation フロントエンドエンジニア/デザイナー

Slide 3

Slide 3 text

もくじ今のフロントエンドを取りまく環境モダンなフレームワークがもたらした陰りアーキテクチャは知ることから始まる具体例で知るアーキテクチャまとめ

Slide 4

Slide 4 text

今のフロントエンドを取りまく環境

Slide 5

Slide 5 text

フロントエンドの外面状態管理ツール有名どころはReduxとVuex 中規模以上の開発では必須のライブラリ言語 TypeScriptがデファクトスタンダートとなりつつある（理由は割愛） React, Vue.js, Angularの三大巨塔 jQueryの採択は減少傾向も現役フレームワーク

Slide 6

Slide 6 text

フロントエンドの内面ビジネスロジック middlewareやactionに記述して UIからは切り離すのが鉄板となっている UI 汎用性の高い再利用コンポーネントを据えて適切な粒度でページコンポーネントを設計していく UI(Local State), Application(Global State) の2つに大別でき別々に管理することが多い状態(state)

Slide 7

Slide 7 text

フロントエンドの内面 “キレイ” ES2015、コンポーネント指向、Flux... などの登場によって今のフロントエンドの内面はとてもにできるようになった

Slide 8

Slide 8 text

パフォーマンス仮想DOMによる効率的なDOM更新が可能になったブラウザ（JavaScriptエンジン）そのものも進化して速くなった実装者はパフォーマンスを意識せずにコーディングができるようになった => パフォーマンスチューニングは気になってからすればよくなった

Slide 9

Slide 9 text

今のフロントエンドの環境はとても恵まれておりなおも進化し続けている

Slide 10

Slide 10 text

jQueryからの移行 - モダンフレームワークでの新規開発 - この流れはまだ変わらない

Slide 11

Slide 11 text

モダンなフレームワークがもたらした陰り

Slide 12

Slide 12 text

なぜフロントエンドに React, Vue.js, Angular を採択するのか

Slide 13

Slide 13 text

パフォーマンスに優れてる - jQueryより保守性に優れてる - SPA開発に向いている - 流行ってるから - よく聞く採択理由

Slide 14

Slide 14 text

パフォーマンスに優れてる - jQueryより保守性に優れてる - SPA開発に向いている - 流行ってるから - よく聞く採択理由

Slide 15

Slide 15 text

パフォーマンスに優れてる - jQueryより保守性に優れてる - SPA開発に向いている - 流行ってるから - よく聞く採択理由本当にそうなのか

Slide 16

Slide 16 text

保守性に優れている理由保守性に優れている理由ビジネスロジック middlewareやactionに記述して UIからは切り離すのが鉄板となっている UI 汎用性の高い再利用コンポーネントを据えて適切な粒度でページコンポーネントを設計していく UI(Local State), Application(Global State) の2つに大別でき別々に管理することが多い状態(state)

Slide 17

Slide 17 text

コンポーネント指向を正しく理解できていなければ保守性に優れたコンポーネントは作れない状態にも種類がありどこでなにを管理すべきかを理解できていなければ保守性に優れた状態管理はできないただしい理解がなければ保守性に優れているものは作れない保守性に優れている理由

Slide 18

Slide 18 text

モダンなフレームワークを使ったから保守性が高くなるわけではない優れた保守性モダンなフレームワーク＝よくある勘違い

Slide 19

Slide 19 text

2016年以降のReactやVue.jsの勢いは凄くあっという間に広まっていったよく分からないままjQueryから移行、新規で導入したプロダクトは少なくはないと思われるその結果生まれたのが・・・

Slide 20

Slide 20 text

人への陰りヤバくなってから対応すればいいという間違った姿勢そもそもヤバい自覚がないコードへの陰りただ管理されてるだけの状態昔の書き方のまま放置された非推奨のコード 1000行越えのファットコンポーネント 2つの陰り

Slide 21

Slide 21 text

2つの陰り陰りはそのまま技術的負債となる jQueryより保守性に優れているのは思想や新しい機能をただしく使えている前提の話

Slide 22

Slide 22 text

今のフロントエンドブラウザやフレームワークの進化でフロントはとてもリッチな資源を得たできることの幅も増えたが、考えるべき事も増えた今のフロントエンドはあり余る資源を管理しないとすぐに収拾がつかなくなる膨大なファットコンポーネント、状態が複雑に絡み合ったアプリケーションの保守性の低さは想像にかたくない jQueryと同じ轍を踏むことになるアーキテクチャだからこそと向き合う必要がある保守性を高める整備もされたが、保守性が低くなりやすくもなった

Slide 23

Slide 23 text

具体例で知るアーキテクチャ

Slide 24

Slide 24 text

あくまで一例です

Slide 25

Slide 25 text

定数はjsonで管理 APIのパス Pageのパスカラーテーマ管理する定数は見極める絶対に腐らない資産となる json形式は言語が変わっても使用できる

Slide 26

Slide 26 text

この機能が要るならあの機能もくるという予測をするやりすぎはオーバーエンジニアリングになるプロダクトの初期〜中期フェーズでよくある今の仕様に合わせるだけだと仕様追加の度に追加の状態や条件文が必要になってくる冗長性を持たせた状態管理

Slide 27

Slide 27 text

canDeleteはTodoを削除できる状態を指す

Slide 28

Slide 28 text

Todoを編集できるようにcanEditを追加した

Slide 29

Slide 29 text

仕様が色々追加された

Slide 30

Slide 30 text

やばみ〜つらみ〜

Slide 31

Slide 31 text

Todoに関する状態をmodeで管理するようにした

Slide 32

Slide 32 text

仕様が追加されても型を修正するだけで済む

Slide 33

Slide 33 text

アーキテクチャは知ることから始まる

Slide 34

Slide 34 text

...etc ソースコード内（アプリケーションの詳細）可読性、冗長性、拡張性、再利用性責務の分離非推奨APIの使用、古い書き方をしていないかフォルダ構成/ファイル名コンポーネント設計状態の仕分と管理方法ビジネスロジック、ユーティリティの管理ソースコード外（アプリケーションの全容）アーキテクチャの範囲

Slide 35

Slide 35 text

アーキテクチャが指し示すものはとても広範囲アプリの見通しの良さに繋がるものが指標になってくる

Slide 36

Slide 36 text

アーキテクチャの考え方アーキテクチャは色々な観点からアプローチできるが重要アプローチ数の多さ切り口は複数ある経験がものを言うコンポーネント設計や状態管理は試行錯誤の末に考え方が身に付く判断どのアプローチが効果的かのは経験によってくる人に教えるのは困難

Slide 37

Slide 37 text

アプローチA アプローチB アプローチC アプローチD 経験による判断 Done

Slide 38

Slide 38 text

アプローチA アプローチB アプローチC アプローチD 経験による判断 Done の中から最良のものを判断 A,B,C

Slide 39

Slide 39 text

アプローチA アプローチB アプローチC アプローチE アプローチD 経験による判断 Done の中から最良のものを判断 A,B,C,E

Slide 40

Slide 40 text

アプローチA アプローチB アプローチC アプローチD 経験による判断 Done A,B,Cの中から最良のものを判断通るアプローチが多いほど柔軟かつ堅牢なアーキテクチャへの考え方ができる

Slide 41

Slide 41 text

アプローチA アプローチF アプローチB アプローチC アプローチD 経験による判断 Done アプローチE F これはでいこうと判断

Slide 42

Slide 42 text

アプローチA アプローチF アプローチB アプローチC アプローチD 経験による判断 Done アプローチE F これはでいこうと判断判断フローはいずれ最適化されていく

Slide 43

Slide 43 text

知るだけでは効果を発揮しないもの（知見）フォルダ構成コンポーネント設計 Store構成短く抽象的な変数名よりも長く説明的な変数名の方が優れている UI部とロジック部を分け責務を分離すると読みやすくなる関数の中で直接関数をbindしない知るだけで効果を発揮するもの（知識）アプローチの種類

Slide 44

Slide 44 text

アーキテクチャとどう向き合うか最初から完璧な設計をすることは不可能であることが多い現時点のベストなアプローチ捨てやすさ、拡張しやすさは後々響いてくるヤバくなってから対応すればいいは非常に危険まずはどのようなアプローチがあるかの知識を知ることが大事累積した知識は結びつくことで知見に昇華するヤバくなっても良いように備えるアプローチの手数を増やす

Slide 45

Slide 45 text

まとめ

Slide 46

Slide 46 text

アーキテクチャは一日にして成らずアプローチの手数を増やそう経験に勝るアプローチはないアーキテクチャに銀の弾丸や完璧は存在しない

Slide 47

Slide 47 text

ご静聴ありがとうございました！