TeachmeBizを支えるフロントエンドのアーキテクチャと品質担保
•
0 likes•3,135 views
2019/10/30 Vue.jsアーキテクチャリング勉強会 https://cw-engineers.connpass.com/event/146975/ 笹木信吾 @ 株式会社スタディスト
Recommended
More Related Content
Similar to TeachmeBizを支えるフロントエンドのアーキテクチャと品質担保
Similar to TeachmeBizを支えるフロントエンドのアーキテクチャと品質担保 (20)
Recently uploaded
Recently uploaded (16)
TeachmeBizを支えるフロントエンドのアーキテクチャと品質担保
- 2. ⾃⼰紹介 • 笹⽊ 信吾 @株式会社スタディスト • 2015卒(27歳) • Rails/Vue がメインのWebエンジニア • ← デグー5匹飼ってます︕ • @HousouP
- 6. 本⽇お話する内容
- 7. 本⽇お話する内容
- 8. 本⽇お話する内容
- 10. Vue/Vuexあるある(※弊社調査) ● Vuexでどこまで状態管理したら良いんだろう︖ ● コンポーネントはどんなふうに分割する︖ ● コンポーネントの品質どうやって評価する︖ ● フロントエンドのテストコードって何書いたらよい︖ 本⽇お話する内容
- 11. 本⽇お話しない内容
- 12. 本⽇お話しない内容 ● vue/vuex 及び周辺技術、ツールの基礎 ● Nuxt ● サーバサイド 本⽇お話しない内容
- 13. Vue/Vuexあるある(※弊社調査)(再掲) ● Vuexでどこまで状態管理したら良いんだろう︖ ● コンポーネントはどんなふうに分割する︖ ● コンポーネントの品質どうやって評価する︖ ● フロントエンドのテストコードって何書いたらよい︖ 本⽇お話する内容
- 18. 画⾯ごとに、画⾯内で使⽤する状態を管理する (画⾯駆動Vuex) Vuexでどこまで状態管理したら良いんだろう︖ マニュアル⼀覧画⾯ マニュアル閲覧画⾯ マニュアル編集画⾯ Store A Store B Store C l マニュアルの⼀覧の取得管理 l ページング情報 l 検索パラメータ l タブの選択状態 l マニュアルの選択状態 l …etc l マニュアルの取得管理 l トグルメニューの開閉状態 l ⼊⼒中のコメント l …etc l マニュアルの取得管理 l 編集中の内容 l 更新系アクションの管理 l …etc
- 19. Vuexでどこまで状態管理したら良いんだろう︖ マニュアル⼀覧画⾯ マニュアル閲覧画⾯ マニュアル編集画⾯ Store A Store B Store C ● 画⾯を構成するコンポーネント間での状態の共有が容易 ● ⼦コンポーネント、孫コンポーネントへのバケツリレーを回避 ● 画⾯単位での設計、実装がしやすく初期開発が素早く⾏える ● 画⾯で独⽴しているので修正の影響範囲が画⾯を越えない 画⾯駆動Vuexのメリット
- 33. ドメイン駆動Vuexによる責務 Vuexでどこまで状態管理したら良いんだろう︖ ● APIにリクエストすること ● レスポンスを保持すること ● レスポンスを整形して返すこと
- 35. state Vuexでどこまで状態管理したら良いんだろう︖ ● 各種APIのレスポンスをそのまま保持する ● 画⾯の状態などは⼀切持たない ● ドメインのリソース単位(マニュアル/ユーザ/フォルダ/…etc) でモジュール分割される
- 36. action Vuexでどこまで状態管理したら良いんだろう︖ ● APIを呼び出してmutationをコミットする ● APIの⼊⼒仕様を唯⼀理解している ● UI側からUI都合の要求を受取り、複雑なAPIリクエストパラメータの構築を吸収
- 38. getter + モデル Vuexでどこまで状態管理したら良いんだろう︖ ● APIの出⼒仕様を唯⼀理解している ● 複雑なAPIレスポンスを、UIにとって理想的なモデルデータに変換、提供する
- 39. ドメイン駆動Vuexによるメリット Vuexでどこまで状態管理したら良いんだろう︖ ● Storeの責務が明確なのでチーム開発でも迷いが⽣じにくい ● UIがサーバサイドの影響を⼀切受けないため、API側の修正や置き換えに対 してもstore側で全て吸収できる ● UIにビジネスロジックが混ざらないためテスタビリティが⾼い
- 41. A. 意外と⾟くない ● コンポーネントを跨いで画⾯全体で使い回したいデータは、⼤半がAPIから取得 したドメインデータでした ● コンポーネント内に閉じた状態ならdataで持てば良いし、多少のバケツリレー は受け⼊れたほうがテスタビリティも⾼い Vuexでどこまで状態管理したら良いんだろう︖
- 42. と⾔いつつ抜け道は⽤意してる Vuexでどこまで状態管理したら良いんだろう︖ モーダルアラート フラッシュメッセージ ● あらゆる画⾯で使⽤するUIの状態管理は例外 ● フラッシュメッセージ ● モーダルアラート ● …etc
- 45. Vue/Vuexあるある(※弊社調査) ● Vuexでどこまで状態管理したら良いんだろう︖ ● コンポーネントはどんなふうに分割する︖ ● コンポーネントの品質どうやって評価する︖ ● フロントエンドのテストコードって何書いたらよい︖ Vuexでどこまで状態管理したら良いんだろう︖
- 49. コンポーネントはどんなふうに分割する︖ ● Webデザインのアプローチ ● UIデザインは化学元素に似ているという発想から、UIパーツを階層化する ● Atoms (原⼦) ● Molecules (分⼦) ● Organisms (有機体) ● Templates (ページテンプレ) ● Pages (画⾯) ※ TeachmeBizはSPAなので、Templatesを使わなかったり、共通Layoutコンポーネントを作ったりのアレンジもあり Atomic Design
- 54. コンポーネントはどんなふうに分割する︖ Atomic Design 分類 ⽤途 Store参照 例 Pages ユーザが⼀度に利⽤する画⾯そのもの 可 Organisms Moleculesを組み合わせてユーザにUXを提供する 可 Molecules Atomsを組み合わせて、単⼀の機能を提供する 不可 Atoms それ以上分割できないUIの最⼩単位 不可
- 55. コンポーネントはどんなふうに分割する︖ Atomic Design のメリット ● 分割の基準が明確で、作りやすい、探しやすい、管理しやすい ● 下位コンポーネントは上位コンポーネントを知る必要が⼀切ないので、再利⽤ 性が⾼いコンポーネントを作りやすい ● storeへアクセスできる層を限定することで、下位コンポーネントのテスタビリ ティが⾼い
- 56. Vue/Vuexあるある(※弊社調査) ● Vuexでどこまで状態管理したら良いんだろう︖ ● コンポーネントはどんなふうに分割する︖ ● コンポーネントの品質どうやって評価する︖ ● フロントエンドのテストコードって何書いたらよい︖ コンポーネントはどんなふうに分割する︖
- 58. ⼤量のコンポーネントの品質どうやって評価する︖ ● Propsの組み合わせごとの挙動を試すの⾯倒 ● 多⾔語の確認するのしんどくない︖ ● APIに依存するようなコンポーネントの動作確認は︖ ● デザイナなどステークホルダとのすり合わせは︖ ● …etc コンポーネントの品質どうやって評価する︖
- 60. Storybookの特徴 コンポーネントの品質どうやって評価する︖ ● コンポーネントをカタログ化して、単体での動作確認を可能にする ● 依存データをモック化することにより、サーバの存在も無視できる ● 必要に応じて依存コンポーネントをモック化するなども可能 ● 豊富すぎるアドオンによって夢が広がる
- 66. ex2. サーバを⽤意せずに画⾯遷移を検証したい コンポーネントの品質どうやって評価する︖ マニュアル一覧 API フォルダ一覧 API サブフォルダ一覧 API 画面遷移画面遷移トップページ フォルダ⼀覧画⾯ サブフォルダ⼀覧画⾯
- 68. storybook上でstoreをモックすることで、サーバなしで画⾯遷移する (実現⽅法) コンポーネントの品質どうやって評価する︖ 詳細は開発ブログに個別記事があります (“スタディスト 開発ブログ” でけんさくけんさくー) https://medium.com/studist-dev/storybook-d879178318b2 ● storybook-router を⽤いて、vue-routerを使えるように ● APIを叩くactionは全て正常系のモックに差し替える ● getterを全てモックに差し替える Storeモックの例(⼀部)
- 70. プルリクの段階で誰でもstorybookを閲覧できるように コンポーネントの品質どうやって評価する︖ ① PushしてCIを実⾏ ④ StorybookのURLを コミットステータスに添付 ② storybookを静的ビルド ③ 成果物をS3にアップロード
- 73. Vue/Vuexあるある(※弊社調査) ● Vuexでどこまで状態管理したら良いんだろう︖ ● コンポーネントはどんなふうに分割する︖ ● APIレスポンスのデータ構造がフロントに馴染まない︖ ● コンポーネントの品質どうやって評価する︖ ● フロントエンドのテストコードって何書いたらよい︖ コンポーネントの動作確認どこまでやる︖
- 75. フロントエンドのテストコードって何書いたらよい︖ フロントエンドのテストコードって何書いたらよい︖ ● Vue/vuexから分離したピュアロジック ● Vueコンポーネント ● VuexのStore 主なテスト対象
- 76. フロントエンドのテストコードって何書いたらよい︖ フロントエンドのテストコードって何書いたらよい︖ ● Vue/vuexから分離したピュアロジック ● Vueコンポーネント ● VuexのStore 主なテスト対象 ※ サーバサイドやvue以外のフロントと⼤差ないので割愛
- 77. フロントエンドのテストコードって何書いたらよい︖ フロントエンドのテストコードって何書いたらよい︖ ● 振る舞いのテスト ● デザインのテスト ● actionのテスト ● mutation のテスト ● getterのテスト コンポーネントのテスト Storeのテスト
- 78. フロントエンドのテストコードって何書いたらよい︖ フロントエンドのテストコードって何書いたらよい︖ ● 振る舞いのテスト ● デザインのテスト ● actionのテスト ● mutation のテスト ● getterのテスト コンポーネントのテスト Storeのテスト
- 79. コンポーネントの振る舞いのテスト フロントエンドのテストコードって何書いたらよい︖ Vue-test-utils を使用して、コンポーネントのprops/dataによる振る舞いの変化を 主に検証する ● atom ● molecule ● organism ● page Organismのコンポーネントだけをテスト対象とする
- 81. フロントエンドのテストコードって何書いたらよい︖ フロントエンドのテストコードって何書いたらよい︖ ● 振る舞いのテスト ● デザインのテスト(実験中) ● actionのテスト ● mutation のテスト ● getterのテスト コンポーネントのテスト Storeのテスト
- 85. Storycap × reg-suit によるスナップショットテスト フロントエンドのテストコードって何書いたらよい︖ ① Storycapで、Storybookの全ストーリーのスクショを取得
- 86. Storycap × reg-suit によるスナップショットテスト フロントエンドのテストコードって何書いたらよい︖ ② 正となるスクショをS3に配置し、CIごとに再度撮影したスクショと⽐較
- 87. Storycap × reg-suit によるスナップショットテスト フロントエンドのテストコードって何書いたらよい︖ ③ 検出した差分を⾒て、正を更新する
- 88. Storycap × reg-suit によるスナップショットテスト フロントエンドのテストコードって何書いたらよい︖ ③ 検出した差分を⾒て、正を更新する
- 89. Storycap × reg-suit によるスナップショットテスト フロントエンドのテストコードって何書いたらよい︖ ③ 検出した差分を⾒て、正を更新する
- 90. Storycap × reg-suit によるスナップショットテスト フロントエンドのテストコードって何書いたらよい︖ ● Storybookのストーリーをある程度スナップショットテストを前提とした構成にする 必要がある ● 前述の、コンポーネントの評価検証のためのStorybookとの使い分けが難しい ● E2Eテスト書いて、その中で取得したスクショを使うのもありかも 依然実験中
- 91. フロントエンドのテストコードって何書いたらよい︖ フロントエンドのテストコードって何書いたらよい︖ ● 振る舞いのテスト ● デザインのテスト ● actionのテスト ● mutation のテスト ● getterのテスト コンポーネントのテスト Storeのテスト
- 92. actionのテスト フロントエンドのテストコードって何書いたらよい︖ ● Actionが責務正しく満たしているかを評価する ● APIリクエストパラメータを正しく組み⽴てること ● 適切なmutationをコミットすること
- 93. actionのテスト フロントエンドのテストコードって何書いたらよい︖ ● Actionが責務正しく満たしているかを評価する ● APIリクエストパラメータを正しく組み⽴てること ● 適切なmutationをコミットすること アクションに id のみを渡した場合 APIへのリクエストパラメータ上の by_name がfalseになる アクションに name のみを渡した場合 APIへのリクエストパラメータ上の by_name がtrueになる axios-mock-adapter でAPIをモック
- 94. actionのテスト フロントエンドのテストコードって何書いたらよい︖ ● Actionが責務正しく満たしているかを評価する ● APIリクエストパラメータを正しく組み⽴てること ● 適切なmutationをコミットすること レスポンスが { id: 1 } の場合 { id: 1} をパラメータにコミットする
- 95. フロントエンドのテストコードって何書いたらよい︖ フロントエンドのテストコードって何書いたらよい︖ ● 振る舞いのテスト ● デザインのテスト ● actionのテスト ● mutation のテスト ● getterのテスト コンポーネントのテスト Storeのテスト
- 96. mutationのテスト フロントエンドのテストコードって何書いたらよい︖ ● mutationが責務正しく満たしているかを評価する ● パラメータに応じてstateを更新(ミューテート)すること
- 98. フロントエンドのテストコードって何書いたらよい︖ フロントエンドのテストコードって何書いたらよい︖ ● 振る舞いのテスト ● デザインのテスト ● actionのテスト ● mutation のテスト ● getterのテスト コンポーネントのテスト Storeのテスト
- 101. storeのテスト総評 フロントエンドのテストコードって何書いたらよい︖ ● テスト対象の責務がわかりやすくなる ● API側の仕様変更によるデグレを検出しやすい ● カバレッジ100%にしようとすると、実装と同じコードをテストでも書くだ けになりがち…。 ● 何をモックして何をテストしているのかの背景を理解しないと、コピペテス トコードが量産されがち…。
- 102. フロントエンドのテストコードって何書いたらよい︖ フロントエンドのテストコードって何書いたらよい︖ ● 振る舞いのテスト ● デザインのテスト ● actionのテスト ● mutation のテスト ● getterのテスト コンポーネントのテスト Storeのテスト カバレッジ (感覚) 10%ぐらい 0%(実験中) 95%ぐらい 95%ぐらい 95%ぐらい
- 103. フロントエンドのテストコードって何書いたらよい︖ フロントエンドのテストコードって何書いたらよい︖ ● 振る舞いのテスト ● デザインのテスト ● actionのテスト ● mutation のテスト ● getterのテスト コンポーネントのテスト Storeのテスト カバレッジ 5%ぐらい 0%(実験中) 95%ぐらい 95%ぐらい 95%ぐらい
- 104. Vue/Vuexあるある(※弊社調査) ● Vuexでどこまで状態管理したら良いんだろう︖ ● コンポーネントはどんなふうに分割する︖ ● コンポーネントの品質どうやって評価する︖ ● フロントエンドのテストコードって何書いたらよい︖ フロントエンドのテストコードって何書いたらよい︖
- 105. まとめ
- 106. TeachmeBizのフロントエンド開発の特徴 ご(清|静)聴ありがとうございました ● ドメイン駆動Vuexで、状態管理をAPIが関わるドメイン領域に限定してるので楽 ● コンポーネントの分割はAtomic Designに従っておけば楽 ● Storybook活⽤しておけば無敵 ● フロントのテストはstore/component共に責務に応じて必要⼗分書く ● スタディスト 開発ブログ 読んでね ● デグーはいいぞ