組織フェーズを見据えたWebフロントエンドのアーキテクチャと変遷

10年間で約15万行のコードを抱え、jQuery -> React + DDD -> React + Redux とアーキテクチャの変遷を辿ってきたChatworkを事例として、 組織フェーズの変化によって発生する課題と、それらをアーキテクチャの観点からどのように乗り越えるか紐解きたいと思います。

Transcript

1. © Chatwork 組織フェーズを見据えた Webフロントエンドの アーキテクチャと変遷 フロントエンド開発部　澁谷　哲也 2021年11月27日
2. 自己紹介 2 Chatwork株式会社 澁谷　哲也 Tetsuya Shibutani フロントエンド開発部　マネージャー ビジネスチャットツールを作っています @shibe_23
3. Chatworkの歴史と組織規模の変遷 (登録ID数:各年12月末時点、2021年のみ9月末時点。従業員数: 各年10月末時点) 登録ID数 フロントエンド チームメンバー数 従業員数 + DDD 🔔 2019/09/24 東証マザーズ上場 81名 87名 109名 154名 247名 3 3名 4名 6名 178.2万ID 241.6万ID 308.0万ID 395.2万ID 458.2万ID 約2.3倍
4. Chatworkのフロントエンドの特徴について 4 Chatworkは歴史のあるプロダクト ◦ リリースから10年 ◦ フロントエンド部分のコードベースで約15万行
5. Chatworkのフロントエンドの特徴について 5 例: メッセージが表示される、タイムライン上の未読ライン • ウィンドウがアクティブかどうか • 表示してから◯秒経過した • メッセージを送信したときは全て既読にする etc... クライアントサイドもビジネスロジックがてんこ盛り • あらゆる状態が1つのページで複雑に絡まり合っている ◦ メッセージ、ルーム、タスク、権限... • ルーティングで特定エンドポイントごとに区切ってリファクタリング、ができない ページという概念がない
6. Chatworkのフロントエンドの特徴について 6 「安全に」「段階的に」リファクタリングをする仕組みが必要 既に社会インフラに近い存在になっている • DAU 96.6万 (2021/9月末時点・最大) • 重篤な不具合 = ユーザーの業務が止まる
7. フロントエンドのアーキテクチャの変遷(1) 7 • 巨大なjQueryベースのSPA • Reactを導入し、ViewとModelの分離を試みた • 段階的にjQueryからReactへ置き換えるため、jQuery部分を明確に分離する必要がある ◦ DDDを元にしたDomain Modelの作成 ◦ ACL(腐敗防止層)によりアーキテクチャを分離し、jQuery部分への依存を制御 複雑化するjQueryからの脱却を目指し、ReactとDDDベースのモデリングを採用 + DDD
8. React + DDD：構成図 8 詳しくは下記blogをご覧ください https://creators-note.chatwork.com/entry/2020/11/04/111353 https://creators-note.chatwork.com/entry/2020/11/09/102425
9. React + DDD：サンプルコード 9 Render (propsの再生成)
10. フロントエンドのアーキテクチャの変遷(2) 10 • Propsを更新する仕組みが自前 • 常に最上位コンポーネントからのレンダリングをするため、レンダリングコストが高い • mutableに状態を管理するため差分比較コストが高い 技術面、組織面の課題からReduxを採用 + DDD 技術的課題 • 組織全体を拡大させていくフェーズに突入したが、実装に独自性が強くオンボーディングコストが高い 組織的課題 ⇒ Redux導入で再レンダリングの範囲を狭める 　 immutableにして差分比較コストを下げる ⇒ デファクトスタンダードである状態管理ライブラリの採用により 　 最初から共通言語で会話できるように
11. Redux採用の効果(1): 再レンダリングの範囲を狭める 11 • react-reduxのuseSelectorを利用 • Storeをsubscribeして、dispatchされる度に差分比 較してくれる • Stateの差分検知・キャッシュ機構により、再レンダ リングの範囲を狭めることができた
12. Redux採用の効果(2): immutableにして差分比較コストを下げる 12 • Redux Toolkitを活用 ◦ immerによってimmutableな実装が可能 • ClassベースのEntityをどうReduxに移行するか ◦ 値はcreateEntityAdapterを使ってStoreに格納 ◦ メソッドはreducerなど種類ごとに分けて関数として定義
13. DDDベースのモデルとReduxの関係 13 • EntityやValue ObjectがStoreに再現しやすい • Application Serviceを見ればRedux化に必要なreducerやselectorが分かる DDDベースのモデルがあることでReduxの導入がスムーズだった クライアントサイドでもビジネスロジックの整理は重要 • 戦術的な考え方を取り入れることはメリットがある • もちろんモデル分析をする姿勢も重要
14. Redux 処理フロー概要図 14
15. Redux ディレクトリ構成(抜粋) 15 • Reduxを導入したコードは application 以下へ • feature単位でreducerやselector、Container Componentをまとめる • 各featureのactionをactions以下にまとめる
16. これから：機能別組織への挑戦とモジュラモノリスを意識した構成へ 16 • Reduxの導入を進めながら、feature単位での分割を行う • モジュラモノリス化を目指して、モノレポ構成への移行を段階的に進める 組織全体で機能型組織への移行を検討 • 採用計画が順調に進み、人数のスケールに関する課題感がより切実なものに • 職能型組織のため、機能開発はプロジェクトごとにメンバーをアサインする形式 ◦ リポジトリのメンテナンスが職能型組織に紐づく ◦ 一つの機能開発で複数のチームに合意をとらなくてはならない ◦ 組織がスケールするほど調整コストがかかり、デリバリーをスケールさせづらい 組織をスケールさせるために、モノリシックなSPAを分割していかなくてはいけない
17. まとめ 17 • 適切なモデリングへの探求 • コードを疎結合に保ち、変更容易性を確保する • 新しいコードと古いコードの境界を設け、依存関係を制御する • 「アーキテクチャで解決すべき課題」は常に変わり続ける アーキテクチャの決定はプロダクトだけでなく、組織フェーズにも影響をうける • 過去のアーキテクチャもプロダクトや組織に貢献していれば負債ではない 環境の変化は激しい。技術的負債を返却しながら新しい環境に適応する必要がある どんなアーキテクチャにするとしても、大事なことは変わらない
18. 最後に 18 JSConf 2021アフターイベントとしてLTに収まらなかった話をします https://chatwork.connpass.com/event/230070/ 12/1(水) 20:00 ~ 21:00 フロントエンド・アーキテクチャの今までとこれから Chatwork Tech Talk #6 󰳒 󰳏 しぶたに たかせ
19. 19 働くをもっと楽しく、創造的に