Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
フロントエンドにおけるアーキテクチャとの向き合い方
Search
camcam_lemon
November 16, 2019
Programming
10
4.8k
フロントエンドにおけるアーキテクチャとの向き合い方
FRONTEND CONFERENCE FUKUOKA2019の登壇資料です
camcam_lemon
November 16, 2019
Tweet
Share
More Decks by camcam_lemon
See All by camcam_lemon
要素のサイズを変えずに押しやすくする
lemon
0
39
iOSのキーボード入力ビューをカスタマイズする
lemon
0
190
視え方と文字の大きさ
lemon
1
370
Yarn WorkSpaces × React Nativeの環境構築
lemon
0
260
UI/UXデザイナーがデザインしてるもの
lemon
2
310
react-reduxで追加されたHooks APIの良い所と使い方
lemon
5
950
ESLintで始めるTypeScriptの静的解析
lemon
8
2k
SEがエンジニアに目覚めデザイナーに転身した冒険譚
lemon
6
1.5k
React.lazyとSuspenseで行うLazy Load
lemon
2
470
Other Decks in Programming
See All in Programming
クリーンアーキテクチャから見る依存の向きの大切さ
shimabox
4
880
Djangoにおける複数ユーザー種別認証の設計アプローチ@DjangoCongress JP 2025
delhi09
PRO
4
380
『GO』アプリ データ基盤のログ収集システムコスト削減
mot_techtalk
0
130
color-scheme: light dark; を完全に理解する
uhyo
6
460
Ruby on cygwin 2025-02
fd0
0
150
第3回関東Kaggler会_AtCoderはKaggleの役に立つ
chettub
3
1.1k
GitHub Actions × RAGでコードレビューの検証の結果
sho_000
0
280
データベースのオペレーターであるCloudNativePGがStatefulSetを使わない理由に迫る
nnaka2992
0
210
お前もAI鬼にならないか?👹Bolt & Cursor & Supabase & Vercelで人間をやめるぞ、ジョジョー!👺
taishiyade
7
4.1k
Formの複雑さに立ち向かう
bmthd
1
890
バックエンドのためのアプリ内課金入門 (サブスク編)
qnighy
8
1.8k
『テスト書いた方が開発が早いじゃん』を解き明かす #phpcon_nagoya
o0h
PRO
6
1.9k
Featured
See All Featured
Mobile First: as difficult as doing things right
swwweet
223
9.3k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3k
Done Done
chrislema
182
16k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
GitHub's CSS Performance
jonrohan
1030
460k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
4
350
Being A Developer After 40
akosma
89
590k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Speed Design
sergeychernyshev
27
800
Making Projects Easy
brettharned
116
6k
Facilitating Awesome Meetings
lara
52
6.2k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7k
Transcript
フロントエンドにおける アーキテクチャとの向き合い方 FRONTEND CONFERENCE FUKUOKA2019
Name 甲斐田 亮一 Twitter @camcam_lemon Company 日本事務器株式会社 Skills TypeScript, React
/ Figma Occupation フロントエンドエンジニア/デザイナー
もくじ 今のフロントエンドを取りまく環境 モダンなフレームワークがもたらした陰り アーキテクチャは知ることから始まる 具体例で知るアーキテクチャ まとめ
今のフロントエンドを取りまく環境
フロントエンドの外面 状態管理ツール 有名どころは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開発に向いている - 流行ってるから - よく聞く採択理由
パフォーマンスに優れてる - 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 経験による判断 Done A,B,Cの中から 最良のものを判断 通るアプローチが多いほど 柔軟かつ堅牢なアーキテクチャへの考え方ができる
アプローチA アプローチF アプローチB アプローチC アプローチD 経験による判断 Done アプローチE F これは
でいこうと判断
アプローチA アプローチF アプローチB アプローチC アプローチD 経験による判断 Done アプローチE F これは
でいこうと判断 判断フローはいずれ最適化されていく
知るだけでは効果を発揮しないもの(知見) フォルダ構成 コンポーネント設計 Store構成 短く抽象的な変数名よりも長く説明的な変数名の方が優れている UI部とロジック部を分け責務を分離すると読みやすくなる 関数の中で直接関数をbindしない 知るだけで効果を発揮するもの(知識) アプローチの種類
アーキテクチャとどう向き合うか 最初から完璧な設計をすることは不可能 であることが多い 現時点のベストなアプローチ 捨てやすさ、拡張しやすさは後々響いてくる ヤバくなってから対応すればいいは非常に危険 まずはどのようなアプローチがあるかの知識を知ることが大事 累積した知識は結びつくことで知見に昇華する ヤバくなっても良いように備える アプローチの手数を増やす
まとめ
アーキテクチャは一日にして成らず アプローチの手数を増やそう 経験に勝るアプローチはない アーキテクチャに銀の弾丸や完璧は存在しない
ご静聴ありがとうございました!