2022年2月9日開催したMeetUP「BrainPad エンジニアトーク #1」資料 (Rtoaster reach+ 開発エンジニア資料)
株式会社ブレインパッド 荒井 悠2022年2月9日Vue2 → Vue3移行・リファクタリング戦略
View Slide
©2022 BrainPad Inc.-2-自己紹介 名前 ● 荒井 悠 所属 ● 株式会社ブレインパッド プロダクトビジネス本部 開発部 趣味 ● ウイスキー ● ゲーム(マリオカート8DX、スプラトゥーン2等)
©2022 BrainPad Inc.-3-話すこと ● Rtoaster reach+において、フロントエンド、バックエンドのリファクタリングを計画して います ● 本日は、フロントエンドのリファクタリング 内容、計画についてご紹介したいと思います
©2022 BrainPad Inc.-4-アジェンダ ● きっかけ ● 何をリファクタリングするのか ● なぜリファクタリングするのか ● どうやってリファクタリングするのか ● いつリファクタリングするのか ● まとめ
©2022 BrainPad Inc.-5-きっかけ
©2022 BrainPad Inc.-6-背景 ● Rtoaster reach+は、最初スピード重視で試作に近い形で開発された →拡張性や可読性はあまり考慮されていなかった ● 本格的に機能拡張を行う段階になり、さまざまな 課題が発覚した ● 課題を解決せずに機能拡張を行っていくと開発の 生産性が低下していき、少しの改修でも膨大な 工数がかかる状態になることが予想されるため、 リファクタリングを行うことに決定した
©2022 BrainPad Inc.-7-何をリファクタリングするのか
©2022 BrainPad Inc.-8-Rtoaster reach+とは ● LINE配信やアプリプッシュ通知を通じて、 顧客とパーソナルにつながり続けるマルチチャネルメッセージングサービス ● 顧客に寄り添った”最適なチャネル“で、”最適な コンテンツ”を、”最適なタイミング”で、簡単に 配信する機能を保有
©2022 BrainPad Inc.-9-Rtoaster reach+とは ● GUIでプレビューを見ながら配信内容を設定
©2022 BrainPad Inc.-10-技術スタック カテゴリー 技術スタック インフラ ● GCP ○ App Engine ○ BigQuery ○ Firestore ○ Dataflow ○ Pub/Sub ○ ほか 言語、ライブラリ ● フロントエンド ○ JavaScript ○ Vue2 ○ Vuex ● バックエンド ○ Python3 ○ Flask 管理画面をGAEで運用しています
©2022 BrainPad Inc.-11-フロントエンドの現状 ● Vue2+Vuexを利用 ● mixinを利用 ● TypeScript未導入 ● Atomic Designを仮導入済み
©2022 BrainPad Inc.-12-なぜリファクタリングするのか
©2022 BrainPad Inc.-13-フロントエンドの課題 ● 下記要因による保守性/可読性の低下 ○ モーダルの独自実装 ○ Vuexの不適切な使い方 ○ mixinの不適切な使い方 ○ 静的な型付けがない ○ Atomic Designを曖昧なルールで導入したため一貫性がない (詳細は後ほど説明させていただきます)
©2022 BrainPad Inc.-14-どうやってリファクタリングするのか
©2022 BrainPad Inc.-15-課題の解決方法 ● モーダルの独自実装 👉Vue2からVue3へ移行 👉Vue3のTeleportに置き換える ● Vuexの不適切な使い方 👉原則Vuexを使用しないようにする ● mixinの不適切な使い方 👉原則mixinを使用しないようにする ● 静的な型付けがない 👉TypeScriptを導入する ● Atomic Designを曖昧なルールで導入したため 一貫性がない 👉ルールを設けて再設計
©2022 BrainPad Inc.-16-Vue2からVue3へ移行 移行理由 ● 現在はVue2を使用しているが、今後はVue3が主流となりいずれ移行が必要になると考えられるため、このタイミングでVue3に移行した方が無駄がないと判断 ● Composition APIを利用できる ○ 分散していた処理を適切にまとめて見通しを 良くできる ● Teleportを利用できる ○ 後述のモーダル改善に利用 ● TypeScriptと相性が良い
©2022 BrainPad Inc.-17-モーダルの独自実装をVue3のTeleportに置き換える リファクタリング前 ● モーダル表示用コンポーネントを定義 ○ Vuexで管理されるstateにmodalitemsを定義 ○ modalitemsにコンポーネントがpushされたらモーダルを表示、popされたら非表示になる 仕組みになっている ● モーダルを表示したい各コンポーネントにて、 表示・非表示したいタイミングでpush/popを行う
©2022 BrainPad Inc.-18-モーダルの独自実装をVue3のTeleportに置き換える リファクタリング後 ● Vue3のTeleportを利用する 参考:https://v3.ja.vuejs.org/guide/teleport.html#vue-コンポーネントと使う
©2022 BrainPad Inc.-19-原則Vuexを使用しないようにする ● 現状、Vuexをただのグローバル変数的に利用している ○ 本来複数の兄弟コンポーネント間で状態を管理する際に煩雑な値のやり取りを簡単にできる メリットがあるが、特にルールが決まって いないため何でもかんでも管理してしまい無駄 が多く、可読性が下がっている ● reach+管理画面の機能規模の小ささを考えると、Vuexを使用せずシンプルなVueでSFCの恩恵を 最大化した方が効率が良いと判断した
©2022 BrainPad Inc.-20-mixinの不適切な利用箇所を改める ● 現状、デザインパターンのTemplate Methodパターンのイメージで、メソッドをオーバーライドのような形で実装する前提となっている箇所がある ○ 挙動が読み解きにくく、実際、不要なAPI呼び出しが複数回実行されたりしていた ● 内容に応じて、ComposableまたはProvide/Inject等を使って共通化する
©2022 BrainPad Inc.-21-TypeScriptの導入 ● 現状、型付けがないことによる可読性の低下や バグのリスクといった課題が挙がっている ● Vue3への移行に合わせてTypeScriptを導入し、 堅牢性を上げたいと考えている
©2022 BrainPad Inc.-22-Atomic Designをベースにしたコンポーネントの再設計 ● 現状は、もともとAtomic Designベースではなかったコンポーネントを無理やりAtomic Designに振り分けた状態のため、一貫性・合理性が低い状態になっている ● atoms、molecules、organisms、pages、layoutsの依存関係や役割を明文化し、 コンポーネントを再構築する ○ 例えば、特定の文脈に依存するコンテンツはpagesやorganismsに実装し、atomsとmoleculesは文脈に依存しない部品として実装するルールとした
©2022 BrainPad Inc.-23-いつリファクタリングするのか
©2022 BrainPad Inc.-24-リファクタリングの進め方 ● ビジネス側からの要望もあり、プロダクトの新規機能開発はできるだけ止めたくない ● しかし、Vue2 → Vue3 移行など、新規機能開発とリファクタリングを並行で進めるとマージ作業が大きな負担となる ● そこで、フロントエンドの開発の無い期間を作り、集中してリファクタリングを行い、完了させることにした ○ バックエンド側の新規機能開発はリファクタリング中も行う
©2022 BrainPad Inc.-25-リファクタリング計画の共有 ● 新規機能開発の人的リソースをリファクタリング側に割く必要があるので、事前にPdM(プロダクトマネージャー)や部長陣にリファクタリングの必要性や進め方を共有し、承認をもらった ○ ↑開発の優先度決定は、開発チームが主体となって関連する部署・人の承認を得ながら決定する体制になっている
©2022 BrainPad Inc.-26-まとめ
©2022 BrainPad Inc.-27-まとめ ● Rtoaster reach+のリファクタリング内容・計画についてお話させていただきました ● 現在は、フロントエンドのベース部分を絶賛実装中です ● 引き続き、開発生産性向上のためリファクタリングを進めていきたいと思います