$30 off During Our Annual Pro Sale. View Details »

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

camcam_lemon
November 16, 2019

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

FRONTEND CONFERENCE FUKUOKA2019の登壇資料です

camcam_lemon

November 16, 2019
Tweet

More Decks by camcam_lemon

Other Decks in Programming

Transcript

  1. フロントエンドにおける

    アーキテクチャとの向き合い方
    FRONTEND CONFERENCE FUKUOKA2019

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  5. フロントエンドの外面
    状態管理ツール
    有名どころはReduxとVuex

    中規模以上の開発では必須のライブラリ
    言語
    TypeScriptがデファクトスタンダート
    となりつつある(理由は割愛)
    React, Vue.js, Angularの三大巨塔
    jQueryの採択は減少傾向も現役
    フレームワーク

    View Slide

  6. フロントエンドの内面
    ビジネスロジック
    middlewareやactionに記述して

    UIからは切り離すのが鉄板となっている
    UI
    汎用性の高い再利用コンポーネントを据えて

    適切な粒度でページコンポーネントを設計していく
    UI(Local State), Application(Global State)

    の2つに大別でき別々に管理することが多い
    状態(state)

    View Slide

  7. フロントエンドの内面
    “キレイ”
    ES2015、コンポーネント指向、Flux...

    などの登場によって今のフロントエンドの内面は


    とても にできるようになった

    View Slide

  8. パフォーマンス
    仮想DOMによる効率的なDOM更新が可能になった


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

    View Slide

  9. 今のフロントエンドの環境は

    とても恵まれており

    なおも進化し続けている

    View Slide

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

    View Slide

  11. モダンなフレームワークが

    もたらした陰り

    View Slide

  12. なぜフロントエンドに

    React, Vue.js, Angular

    を採択するのか

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  16. 保守性に優れている理由
    保守性に優れている理由
    ビジネスロジック
    middlewareやactionに記述して

    UIからは切り離すのが鉄板となっている
    UI
    汎用性の高い再利用コンポーネントを据えて

    適切な粒度でページコンポーネントを設計していく
    UI(Local State), Application(Global State)

    の2つに大別でき別々に管理することが多い
    状態(state)

    View Slide

  17. コンポーネント指向を正しく理解できていなければ

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

    保守性に優れた状態管理はできない
    ただしい理解がなければ

    保守性に優れているものは作れない
    保守性に優れている理由

    View Slide

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

    View Slide

  19. 2016年以降のReactやVue.jsの勢いは凄く

    あっという間に広まっていった

    よく分からないままjQueryから移行、新規で導入した

    プロダクトは少なくはないと思われる

    その結果生まれたのが・・・

    View Slide

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

    View Slide

  21. 2つの陰り
    陰りはそのまま技術的負債となる
    jQueryより保守性に優れているのは

    思想や新しい機能をただしく使えている前提の話

    View Slide

  22. 今のフロントエンド
    ブラウザやフレームワークの進化でフロントはとてもリッチな資源を得た
    できることの幅も増えたが、考えるべき事も増えた
    今のフロントエンドはあり余る資源を管理しないとすぐに収拾がつかなくなる
    膨大なファットコンポーネント、状態が複雑に絡み合ったアプリケーションの

    保守性の低さは想像にかたくない
    jQueryと同じ轍を踏むことになる
    アーキテクチャ
    だからこそ と向き合う必要がある
    保守性を高める整備もされたが、保守性が低くなりやすくもなった

    View Slide

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

    View Slide

  24. あくまで一例です

    View Slide

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

    View Slide

  26. この機能が要るならあの機能もくるという予測をする
    やりすぎはオーバーエンジニアリングになる
    プロダクトの初期〜中期フェーズでよくある
    今の仕様に合わせるだけだと仕様追加の度に

    追加の状態や条件文が必要になってくる
    冗長性を持たせた状態管理

    View Slide

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

    View Slide

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

    View Slide

  29. 仕様が色々追加された

    View Slide

  30. やばみ〜つらみ〜

    View Slide

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

    View Slide

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

    View Slide

  33. アーキテクチャは

    知ることから始まる

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  38. アプローチA
    アプローチB アプローチC
    アプローチD
    経験による判断
    Done
    の中から

    最良のものを判断
    A,B,C

    View Slide

  39. アプローチA
    アプローチB アプローチC
    アプローチE
    アプローチD
    経験による判断
    Done
    の中から

    最良のものを判断
    A,B,C,E

    View Slide

  40. アプローチA
    アプローチB アプローチC
    アプローチD
    経験による判断
    Done
    A,B,Cの中から

    最良のものを判断
    通るアプローチが多いほど

    柔軟かつ堅牢なアーキテクチャへの考え方ができる

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  45. まとめ

    View Slide

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

    View Slide

  47. ご静聴ありがとうございました!

    View Slide