Vue2 → Vue3移行・リファクタリング戦略

株式会社ブレインパッド　荒井悠
2022年2月9日
Vue2 → Vue3移行・リファクタリング戦略

View Slide

©2022 BrainPad Inc.
-2-
自己紹介 
名前 
● 荒井悠 
 
所属 
● 株式会社ブレインパッド 
　　　　プロダクトビジネス本部開発部 
 
趣味 
● ウイスキー 
● ゲーム（マリオカート8DX、スプラトゥーン2等） 

View Slide

-3-
話すこと 
● Rtoaster reach+において、フロントエンド、バックエンド
のリファクタリングを計画して 
います 
● 本日は、フロントエンドのリファクタリング 
内容、計画についてご紹介したいと思います 

View Slide

-4-
アジェンダ 
● きっかけ 
● 何をリファクタリングするのか 
● なぜリファクタリングするのか 
● どうやってリファクタリングするのか 
● いつリファクタリングするのか 
● まとめ 

View Slide

-5-
きっかけ 

View Slide

-6-
背景 
● Rtoaster reach+は、最初スピード重視で試作に近い形
で開発された 
　→拡張性や可読性はあまり考慮されていなかった 
● 本格的に機能拡張を行う段階になり、さまざまな 
課題が発覚した 
● 課題を解決せずに機能拡張を行っていくと開発の 
生産性が低下していき、少しの改修でも膨大な 
工数がかかる状態になることが予想されるため、 
リファクタリングを行うことに決定した 

View Slide

-7-
何をリファクタリングするのか 

View Slide

-8-
Rtoaster reach+とは 
● LINE配信やアプリプッシュ通知を通じて、 
顧客とパーソナルにつながり続けるマルチチャネルメッ
セージングサービス 
● 顧客に寄り添った”最適なチャネル“で、”最適な 
コンテンツ”を、”最適なタイミング”で、簡単に 
配信する機能を保有 

View Slide

-9-
Rtoaster reach+とは 
● GUIでプレビューを見ながら配信内容を設定 

View Slide

-10-
技術スタック 
カテゴリー  技術スタック 
インフラ  ● GCP 
○ App Engine 
○ BigQuery 
○ Firestore 
○ Dataflow 
○ Pub/Sub 
○ ほか 
言語、ライブラリ  ● フロントエンド 
○ JavaScript 
○ Vue2 
○ Vuex 
● バックエンド 
○ Python3 
○ Flask 
管理画面をGAEで運
用しています

View Slide

-11-
フロントエンドの現状 
● Vue2＋Vuexを利用 
● mixinを利用 
● TypeScript未導入 
● Atomic Designを仮導入済み 

View Slide

-12-
なぜリファクタリングするのか 

View Slide

-13-
フロントエンドの課題 
● 下記要因による保守性/可読性の低下 
○ モーダルの独自実装 
○ Vuexの不適切な使い方 
○ mixinの不適切な使い方 
○ 静的な型付けがない 
○ Atomic Designを曖昧なルールで導入したため一
貫性がない 
 
 
（詳細は後ほど説明させていただきます） 

View Slide

-14-
どうやってリファクタリングするのか 

View Slide

-15-
課題の解決方法 
● モーダルの独自実装 
👉Vue2からVue3へ移行 
👉Vue3のTeleportに置き換える 
● Vuexの不適切な使い方 
👉原則Vuexを使用しないようにする 
● mixinの不適切な使い方 
👉原則mixinを使用しないようにする 
● 静的な型付けがない 
👉TypeScriptを導入する 
● Atomic Designを曖昧なルールで導入したため 
一貫性がない 
👉ルールを設けて再設計 

View Slide

-16-
Vue2からVue3へ移行 
移行理由 
● 現在はVue2を使用しているが、今後はVue3が主流とな
りいずれ移行が必要になると考えられるため、このタイ
ミングでVue3に移行した方が無駄がないと判断 
● Composition APIを利用できる 
○ 分散していた処理を適切にまとめて見通しを 
良くできる 
● Teleportを利用できる 
○ 後述のモーダル改善に利用 
● TypeScriptと相性が良い 

View Slide

-17-
モーダルの独自実装をVue3のTeleportに置き換える 
リファクタリング前 
● モーダル表示用コンポーネントを定義 
○ Vuexで管理されるstateにmodalitemsを定義 
○ modalitemsにコンポーネントがpushされたらモーダ
ルを表示、popされたら非表示になる 
仕組みになっている 
● モーダルを表示したい各コンポーネントにて、 
表示・非表示したいタイミングでpush/popを行う 

View Slide

-18-
モーダルの独自実装をVue3のTeleportに置き換える 
リファクタリング後 
● Vue3のTeleportを利用する 
参考：https://v3.ja.vuejs.org/guide/teleport.html#vue-コンポーネントと使う  

View Slide

-19-
原則Vuexを使用しないようにする 
● 現状、Vuexをただのグローバル変数的に利用している 
○ 本来複数の兄弟コンポーネント間で状態を管理す
る際に煩雑な値のやり取りを簡単にできる 
メリットがあるが、特にルールが決まって 
いないため何でもかんでも管理してしまい無駄 
が多く、可読性が下がっている 
● reach+管理画面の機能規模の小ささを考えると、Vuex
を使用せずシンプルなVueでSFCの恩恵を 
最大化した方が効率が良いと判断した 

View Slide

-20-
mixinの不適切な利用箇所を改める 
● 現状、デザインパターンのTemplate Methodパターンの
イメージで、メソッドをオーバーライドのような形で実装
する前提となっている箇所がある 
○ 挙動が読み解きにくく、実際、不要なAPI呼び出し
が複数回実行されたりしていた 
● 内容に応じて、ComposableまたはProvide/Inject等を
使って共通化する 

View Slide

-21-
TypeScriptの導入 
● 現状、型付けがないことによる可読性の低下や 
バグのリスクといった課題が挙がっている 
● Vue3への移行に合わせてTypeScriptを導入し、 
堅牢性を上げたいと考えている 

View Slide

-22-
Atomic Designをベースにしたコンポーネントの再設計 
● 現状は、もともとAtomic Designベースではなかったコン
ポーネントを無理やりAtomic Designに振り分けた状態
のため、一貫性・合理性が低い状態になっている 
● atoms、molecules、organisms、pages、layoutsの依存関
係や役割を明文化し、 
コンポーネントを再構築する 
○ 例えば、特定の文脈に依存するコンテンツはpages
やorganismsに実装し、atomsとmoleculesは文脈に
依存しない部品として実装するルールとした 

View Slide

-23-
いつリファクタリングするのか 

View Slide

-24-
リファクタリングの進め方 
● ビジネス側からの要望もあり、プロダクトの新規機能開
発はできるだけ止めたくない 
● しかし、Vue2 → Vue3 移行など、新規機能開発とリファ
クタリングを並行で進めるとマージ作業が大きな負担と
なる 
● そこで、フロントエンドの開発の無い期間を作り、集中し
てリファクタリングを行い、完了させることにした 
○ バックエンド側の新規機能開発はリファクタリング
中も行う 

View Slide

-25-
リファクタリング計画の共有 
● 新規機能開発の人的リソースをリファクタリング側に割
く必要があるので、事前にPdM（プロダクトマネー
ジャー）や部長陣にリファクタリングの必要性や進め方
を共有し、承認をもらった 
○ ↑開発の優先度決定は、開発チームが主体となっ
て関連する部署・人の承認を得ながら決定する体
制になっている 

View Slide

-26-
まとめ 

View Slide

-27-
まとめ 
● Rtoaster reach+のリファクタリング内容・計画について
お話させていただきました 
● 現在は、フロントエンドのベース部分を絶賛実装中です 
● 引き続き、開発生産性向上のためリファクタリングを進
めていきたいと思います 

View Slide

Vue2 → Vue3移行・リファクタリング戦略

Vue2 → Vue3移行・リファクタリング戦略

BrainPad

More Decks by BrainPad

Other Decks in Programming

Featured

Transcript