FRONTEND CONFERENCE FUKUOKA2019の登壇資料です
フロントエンドにおけるアーキテクチャとの向き合い方FRONTEND CONFERENCE FUKUOKA2019
View Slide
Name 甲斐田 亮一Twitter @camcam_lemonCompany 日本事務器株式会社Skills TypeScript, React / FigmaOccupation フロントエンドエンジニア/デザイナー
もくじ今のフロントエンドを取りまく環境モダンなフレームワークがもたらした陰りアーキテクチャは知ることから始まる具体例で知るアーキテクチャまとめ
今のフロントエンドを取りまく環境
フロントエンドの外面状態管理ツール有名どころはReduxとVuex中規模以上の開発では必須のライブラリ言語TypeScriptがデファクトスタンダートとなりつつある（理由は割愛）React, Vue.js, Angularの三大巨塔jQueryの採択は減少傾向も現役フレームワーク
フロントエンドの内面ビジネスロジックmiddlewareやactionに記述してUIからは切り離すのが鉄板となっているUI汎用性の高い再利用コンポーネントを据えて適切な粒度でページコンポーネントを設計していくUI(Local State), Application(Global State)の2つに大別でき別々に管理することが多い状態(state)
フロントエンドの内面“キレイ”ES2015、コンポーネント指向、Flux...などの登場によって今のフロントエンドの内面はとても にできるようになった
パフォーマンス仮想DOMによる効率的なDOM更新が可能になったブラウザ（JavaScriptエンジン）そのものも進化して速くなった実装者はパフォーマンスを意識せずにコーディングができるようになった=> パフォーマンスチューニングは気になってからすればよくなった
今のフロントエンドの環境はとても恵まれておりなおも進化し続けている
jQueryからの移行-モダンフレームワークでの新規開発-この流れはまだ変わらない
モダンなフレームワークがもたらした陰り
なぜフロントエンドにReact, Vue.js, Angularを採択するのか
パフォーマンスに優れてる-jQueryより保守性に優れてる-SPA開発に向いている-流行ってるから-よく聞く採択理由
パフォーマンスに優れてる-jQueryより保守性に優れてる-SPA開発に向いている-流行ってるから-よく聞く採択理由本当にそうなのか
保守性に優れている理由保守性に優れている理由ビジネスロジックmiddlewareやactionに記述してUIからは切り離すのが鉄板となっているUI汎用性の高い再利用コンポーネントを据えて適切な粒度でページコンポーネントを設計していくUI(Local State), Application(Global State)の2つに大別でき別々に管理することが多い状態(state)
コンポーネント指向を正しく理解できていなければ保守性に優れたコンポーネントは作れない状態にも種類がありどこでなにを管理すべきかを理解できていなければ保守性に優れた状態管理はできないただしい理解がなければ保守性に優れているものは作れない保守性に優れている理由
モダンなフレームワークを使ったから保守性が高くなるわけではない優れた保守性モダンなフレームワーク＝よくある勘違い
2016年以降のReactやVue.jsの勢いは凄くあっという間に広まっていったよく分からないままjQueryから移行、新規で導入したプロダクトは少なくはないと思われるその結果生まれたのが・・・
人への陰りヤバくなってから対応すればいいという間違った姿勢そもそもヤバい自覚がないコードへの陰りただ管理されてるだけの状態昔の書き方のまま放置された非推奨のコード1000行越えのファットコンポーネント2つの陰り
2つの陰り陰りはそのまま技術的負債となるjQueryより保守性に優れているのは思想や新しい機能をただしく使えている前提の話
今のフロントエンドブラウザやフレームワークの進化でフロントはとてもリッチな資源を得たできることの幅も増えたが、考えるべき事も増えた今のフロントエンドはあり余る資源を管理しないとすぐに収拾がつかなくなる膨大なファットコンポーネント、状態が複雑に絡み合ったアプリケーションの保守性の低さは想像にかたくないjQueryと同じ轍を踏むことになるアーキテクチャだからこそ と向き合う必要がある保守性を高める整備もされたが、保守性が低くなりやすくもなった
具体例で知るアーキテクチャ
あくまで一例です
定数はjsonで管理APIのパスPageのパスカラーテーマ管理する定数は見極める絶対に腐らない資産となるjson形式は言語が変わっても使用できる
この機能が要るならあの機能もくるという予測をするやりすぎはオーバーエンジニアリングになるプロダクトの初期〜中期フェーズでよくある今の仕様に合わせるだけだと仕様追加の度に追加の状態や条件文が必要になってくる冗長性を持たせた状態管理
canDeleteはTodoを削除できる状態を指す
Todoを編集できるようにcanEditを追加した
仕様が色々追加された
やばみ〜つらみ〜
Todoに関する状態をmodeで管理するようにした
仕様が追加されても型を修正するだけで済む
アーキテクチャは知ることから始まる
...etcソースコード内（アプリケーションの詳細）可読性、冗長性、拡張性、再利用性責務の分離非推奨APIの使用、古い書き方をしていないかフォルダ構成/ファイル名コンポーネント設計状態の仕分と管理方法ビジネスロジック、ユーティリティの管理ソースコード外（アプリケーションの全容）アーキテクチャの範囲
アーキテクチャが指し示すものはとても広範囲アプリの見通しの良さに繋がるものが指標になってくる
アーキテクチャの考え方アーキテクチャは色々な観点からアプローチできるが重要アプローチ数の多さ切り口は複数ある経験がものを言うコンポーネント設計や状態管理は試行錯誤の末に考え方が身に付く判断どのアプローチが効果的かの は経験によってくる人に教えるのは困難
アプローチAアプローチB アプローチCアプローチD経験による判断Done
アプローチAアプローチB アプローチCアプローチD経験による判断Doneの中から最良のものを判断A,B,C
アプローチAアプローチB アプローチCアプローチEアプローチD経験による判断Doneの中から最良のものを判断A,B,C,E
アプローチAアプローチB アプローチCアプローチD経験による判断DoneA,B,Cの中から最良のものを判断通るアプローチが多いほど柔軟かつ堅牢なアーキテクチャへの考え方ができる
アプローチAアプローチFアプローチB アプローチCアプローチD経験による判断DoneアプローチEFこれは でいこうと判断
アプローチAアプローチFアプローチB アプローチCアプローチD経験による判断DoneアプローチEFこれは でいこうと判断判断フローはいずれ最適化されていく
知るだけでは効果を発揮しないもの（知見）フォルダ構成コンポーネント設計Store構成短く抽象的な変数名よりも長く説明的な変数名の方が優れているUI部とロジック部を分け責務を分離すると読みやすくなる関数の中で直接関数をbindしない知るだけで効果を発揮するもの（知識）アプローチの種類
アーキテクチャとどう向き合うか最初から完璧な設計をすることは不可能であることが多い現時点のベストなアプローチ捨てやすさ、拡張しやすさは後々響いてくるヤバくなってから対応すればいいは非常に危険まずはどのようなアプローチがあるかの知識を知ることが大事累積した知識は結びつくことで知見に昇華するヤバくなっても良いように備えるアプローチの手数を増やす
まとめ
アーキテクチャは一日にして成らずアプローチの手数を増やそう経験に勝るアプローチはないアーキテクチャに銀の弾丸や完璧は存在しない
ご静聴ありがとうございました！
lemon
niftycorp
okuramasafumi
tnishinaga
riku929hr
ryounasso
kasacchiful
piyoppi
hiroyaonoe
deepu105
.jpg){kind=avatar}
yumnumm
kneath
pauljervisheath
yeseniaperezcruz
garrettdimon
brettharned
davidbonilla
chriscoyier
quramy
lara
addyosmani
rasmusluckow