プロダクト横断を見据えた刷新プロジェクトのフロントエンド開発 / front-end development in revamp project

GeekGig 『スタディサプリ x Showcase Gig』 〜フロントエンドを楽しむ〜

Transcript

1. プロダクト横断を見据えた 刷新プロジェクトのフロントエンド開発 2021/11/18@GeekGig
2. 自己紹介 • 成嶋大樹（なるしまだいき） • 次世代店舗創出プラットフォーム「O:derプラットフォーム」の開 発において、O:der ToGoを担当 • ReactとTypeScriptが好き 2 株式会社Showcase Gig フロントエンドエンジニア dnrsm
3. 今日話すこと プロダクト横断を見据えた 刷新プロジェクトのフロントエンド開発 3
4. アジェンダ • 刷新プロジェクトについて • プロダクト横断のコンポーネントについて • コンポーネントの設計で気をつけたこと • プロダクトの実装・技術スタック • 振り返りと学び 4
5. 1. 刷新プロジェクトについて 5
6. Product Backend やろうとしてること 6
7. 何を刷新するのか • Platformからフロントエンドまで技術刷新を行う ◦ 今回話すのはフロントエンドについて • Vue→Reactベースの技術スタックに置き換える • デザインも全く新しいものに置き換わる ◦ それに伴いデザインシステムも構築する • UI/UXを統一するためのコンポーネント基盤を作る 7
8. 以前まではどうやっていたか • テイクアウトもテーブルオーダーも全く別のデザイン • 担当するチームがそれぞれ別のリポジトリで作業をしていた 8
9. O:der Backend Shared Components 9 何を刷新するのか
10. どうやって進めるのか • Yarn Workspaceでmonorepo構成に ◦ ひとつのリポジトリで複数の packageを管理 する • 各packageを担当するチームが独立して 作業をする ◦ 影響範囲を明確にする 10
11. どうやって進めるのか • eslint, tsconfig, prettierの設定を共通化 ◦ monorepoなのでルートに置いて各 package でextendsする形で利用 11
12. 2. プロダクト横断のコンポーネントについて 12
13. O:der Backend Shared Components 13
14. Shared Componentsとは • 現状はOSSにはせず社内だけで使うコンポーネントライブラリ • toCプロダクトのデザインシステム • これをもとにテイクアウトアプリやイートインアプリを作る 14
15. なぜ作るのか • ユーザー体験や振る舞いを統一したい • 一貫したデザインによりユーザー体験を向上させる • 価値提供のスピードを向上させる • コンポーネントの作り方に一貫したルールができる 15
16. 何を作ったのか 大きく分けると以下の3つ • 基礎的なUIパーツ • Brandingのためのパーツ • headlessなUIパーツ 16
17. 基礎的なUIパーツ 17 • 外観を持つ抽象的な基礎コンポーネント • ButtonやTextFieldなど
18. Brandingのためのコンポーネント • 色・フォント・アイコンなどBrandingのためのコンポーネント • Typography, Iconなど 18
19. HeadlessなUIパーツ • 外観は持たず振る舞いとしての機能のみを持つ • ModalやTransitionなど • 細かいインタラクションなどもプロダクト間で統一できるように共通化 19
20. コンポーネントの責務について • 共通コンポーネント ◦ Atomic Designでいうところの、Atoms, Moleculesを主に実装する ◦ ローカルステート（useState）とロジックはなるべく持たないように • プロダクト側のコンポーネント ◦ Atomic DesignでいうところのOrganims, Templatesを主に実装する ◦ データの取得・更新やロジックを含めて良い 20
21. どう作ったのか 主な技術スタック • React • TypeScript • CSS Modules プロダクト側のアーキテクチャで使いやすいように、純粋なReactコンポーネントとして提 供する 21
22. コンポーネントカタログの提供 22
23. コンポーネントカタログの提供 • ChromaticというUIテストやホスティングをしてくれるサービスを使って Storybookを公開してい る • どんなコンポーネントがあるのか一覧化することができる • コンポーネントの表示パターンや挙動や型情報を確認できる ◦ オンボーディングコストが下がる 23
24. 3. コンポーネント設計で気をつけたこと 24
25. コンポーネント設計で気をつけたこと 1. プロダクトのコンテクストに引っ張られないように 2. 早まった共通化・抽象化をしないように 25
26. プロダクトのコンテクストに引っ張られないように 26
27. どう作ったのか（再掲） 主な技術スタック • React • TypeScript • CSS Modules プロダクト側のアーキテクチャで使いやすいように、純粋なReactコンポーネントとして提 供する 27
28. プロダクト側のコンテキストに引っ張られないように • Tagコンポーネントを例にすると、下の2つで共通なのは色がオレンジということだけ • 「注文済み」というコンテキストにつられて、オレンジの状態にしたいときにtype="orderComplete" のようにするのはNG • colorScheme="orange"のような色の情報だけを持つ汎用的なPropsにする 28
29. O:der Backend Shared Components 29 プロダクト側のコンテキストに引っ張られないように
30. • 共通コンポーネントは親からどのように利用されるかを知らない • 各Propsにどのような値を渡すかは親の責務 • 共通コンポーネントのPropsはプロダクト側のコンテキストに合わせず抽象的にする プロダクト側のコンテキストに引っ張られないように 30
31. 早まった共通化・抽象化をしないように 31
32. やってしまったこと • プロダクト側のコンポーネントも頑張って抽象化しようとしてしまう ◦ 再利用を目的としてしまう • 安易にDRYにしようとしてしまう ◦ 同じようなことをしているから共通化して論理的凝集することが多かった ◦ プロダクト間でのユースケースを知る前に共通化しようとしてしまう 32
33. 再利用化を目的とするあまり、副作用が多く脆弱な コンポーネントが出来上がってしまった 33
34. App Component A Page A Page B Component B Component C 34
35. モジュールはたったひとつのアクターに対して責務を負うべきである 『Clean Architecture』SRP: 単一責任の原則 より 35
36. • 要するに、変更理由が一つであれば疎結合で依存性が少なくて済む • コンポーネントに名前をつけるときにしっくりくる名前が思いつかない場合、「複数の 責務を持っている」ことが多い ◦ 1つだけであればやっていることを命名すれば良いので楽 36
37. App Component A Page A Page B Component C Component D Component B 37
38. どうすれば良かったのか • プロダクト側のコンポーネントはAtomic DesignでいうところのOrganismsと Templatesを主に実装する。ビジネスロジックとドメイン知識が入り込みやすいコン ポーネントなので、共通化するときは慎重に見極めることが大事。 • 共通化できる場合もあるだろうけど、いずれにせよ慎重に • アクターが異なる場合、最初から分離しておく 38
39. どうすれば良かったのか • はじめの段階では限定的なコンポーネントとして実装する • 共通化できそうなタイミングでリファクタリングをすれば良い 39
40. 4. プロダクトの実装・技術スタック 40
41. プロダクトの実装・技術スタックについて 1. Next.jsの採用について 2. スキーマファースト開発 41
42. 　Next.jsの採用について 42
43. Next.jsの採用について • SSR/SSG/ハイブリッドなど要件に合わせやすい • ファイルベースルーティング ◦ pages/配下にファイルを置けばルーティングされるので、 react-router使って頑張って書 かなくて良いので楽 • ゼロコンフィグ ◦ Webpackまわりなどの足回りが揃った状態から開発を始められる ◦ すぐにReact書き始められるので効率的 43
44. スキーマファースト開発 44
45. 以前までは • OpenAPIを使ってはいたが放置されがちだった • openapi-generatorとか使ってないのでAPI通信まわりは自前実装 • APIまわりの型も書いたり書いてなかったり • APIの変更に追従しづらいので開発効率が悪かった 45
46. スキーマファースト開発 • OpenAPIを使ってAPIドキュメントを記述しています • スキーマからモックサーバーを使って開発を始められるので、バックエンドの実装 が終わるのを待たずにAPIと結合した開発が進められる • openapi-generatorでAPIクライアントと型を生成しているので、APIの変更に追従し やすく、クライアントとサーバー間で齟齬も起こりにくい 46
47. 振り返りと学び • チームで独立して作業できる状態にはなった • コンポーネント実装の基本的なルールはできた • 共通コンポーネントは抽象的に作ることを常に意識する • コンポーネントについては最初は分離した状態で限定的なコンポーネントとして実 装した方が良さそう • 設計に銀の弾丸というものはないので、サービスの成長とともにリファクタリングは 継続していく 47
48. ご清聴ありがとうございました 48