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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

Slide 24

Slide 24 text

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