フロントエンド技術の波を乗り越える！Vue2からReactへの移行とアーキテクチャ設計による堅牢化

フロントエンド技術の変化に翻弄されることなく、ソフトウェアのコアを守り抜くことが重要です。今回は、Vue2からVue3への移行検討で課題に直面した事例を紹介します。大規模な書き換えが必要だったため、Reactへの移行とフロントエンドコードのクリーンアーキテクチャによる再設計を行い、コアロジックを守りぬくことができました。フロントエンド技術の変化に左右されないソフトウェア設計の方法を解説します。

関連ブログ：https://dev.classmethod.jp/articles/vue2-to-react-migration-and-frontend-clean-architecture/

Transcript

1. 1 / 70 フロントエンド技術の波を乗り越える！ Vue2からReactへの移行とアーキテクチャ設計による堅牢化 2024.7.30 クラスメソッド株式会社 産業支援グループ リテールアプリ共創部 中野ヨシユキ
2. 2 / 70 中野ヨシユキ (@engin_yo) 所属: クラスメソッド 産業支援グループ リテールアプリ共創部 やってること: LINE ミニアプリの機能開発、保守、運用 ロール: ソフトウェアエンジニア 趣味: ランニング、自作キーボード 自己紹介
3. 3 / 70 このセッションでは、私の経験と学びを共有します 一方で、本セッションの内容が、すべてのプロジェクトやチームに適用できるわけではないことを ご理解ください また、特定の技術や手法を批判するわけではないこと、ご理解ください 本日のセッションから1つでも何かを持ち帰っていただき、ソフトウェア開発や保守に活かしてい ただけるとうれしいです はじめに
4. 4 / 70 レガシーなソフトウェアの保守がつらいと思っている方 初期開発の担当者がいない中、ソフトウェアのエンハンスを迫られている方 ソフトウェアアーキテクチャ理論の実践に興味がある方 本セッションのターゲット
5. 5 / 70 Vue2からReactへリライトを意思決定した理由 リライトヘ当たって直面した課題 課題を解決するための取り組み フロントエンドクリーンアーキテクチャ導入解説 リライト後の変化 学んだ教訓 目次
6. 6 / 70 Vue2からReactへリライトを意思決定した理由
7. 7 / 70 Vue2は2023年12月末に EOL (End of Life) を迎えていた 参考: https://v2.vuejs.org/eol/ 正規ルートだと「Vue2からVue3」 、現トレンドだと「Vue2からReact」にするか、世間では大きく 2つのルートに分かれていた Vue 2 の最新リリースである 2.7.16 は、Vue 2 の最終リリース。2.7 機能の最終的な修正が含まれ ており、さらに、Vue 3 との型の整合性がある 理由1: Vue2のEOL
8. 8 / 70 Options APIを利用している場合、Composition APIへの置き換えが必要 Vue2だと、各コンポーネントのthisに状態を変更するロジックが依存するため関心事の単位で関数 をまとめることが難しく、Options APIを利用するコード周辺に分散しがちで「状態を持つ関数」 の再利用しにくい Vue2に関連付属するライブラリの置き換えが必要 例： Vuetify VueCLI 理由2： Vue2からVue3の移行のコスト
9. 9 / 70 Vue2の場合（コンポーネントがthis依存） 理由2： Vue2からVue3の移行のコスト import Vue from "vue/dist/vue.esm"; new Vue({ el: "#app", data: { message: "This is Vue 2", count: 0, }, methods: { increment() { this.count++; }, decrement() { this.count--; }, }, template: ` <div> <p>Count: {{ count }}</p> <button @click="increment">Increment</button> <button @click="decrement">Decrement</button> </div>
10. 10 / 70 Vue3の場合（Composition APIによる関数再利用） 理由2： Vue2からVue3の移行のコスト import { createApp, ref } from "vue"; import { useCounter } from "./useCounter"; const App = { setup() { const message = ref("This is Vue 3"); const { count, increment, decrement } = useCounter(); return { message, count, increment, decrement, }; }, template: ` <div> <p>Count: {{ count }}</p> <button @click="increment">Increment</button> <button @click="decrement">Decrement</button> </div> `, };
11. 11 / 70 import { ref } from "vue"; export const useCounter = () => { const count = ref(0); const increment = () => { count.value++; }; const decrement = () => { count.value--; }; return { count, increment, decrement, }; };
12. 12 / 70 Reactは現行のトレンドだとVueよりも主流になっている 今後、追加の機能開発をすすめていく場合は、私たちのチームでVueよりも開発工数が少なめで対 応可能であると判断 参考： State of JavaScript 2023 Front-end Frameworks 理由3: React主流による保守体制確保の容易性
13. 13 / 70 私たちLINEミニアプリ運用保守チームは、技術スタックを可能な限りそろえる方針をとっており、 技術への認知負荷低減を目標にしている 目的としては、チームが顧客へ価値提供する速度を上げるため 理由4: チームの技術スタックをそろえることによる効用
14. 14 / 70 システムエントロピーという概念 定義 組織全体で技術スタックが統一されていれば「エントロピーは低い」 バラバラな技術が採用されていれば「エントロピーは高い」 特徴 エントロピー低い状態 システムのエントロピーが低ければ低いほど、システム理解は簡単 改修のハードルが低く、トイル(手作業)の削減や自動化を推進しやすい エントロピー高い状態 エントロピーが高くなると、システム理解に時間がかかりやすい 自動化や改善のハードルや手間が高まる傾向にある 参考：Satoshi Tajima 「システムのエントロピーをコントロールすることの大切さ」より 理由4: チームの技術スタックをそろえることによる効用
15. 15 / 70 標準スタック フロントエンド：React、TypeScript バックエンド：Node.js（Express） 、TypeScript インフラ：AWS, Google Cloud, AWS CDKやCDKTfなどのIaCサービス 実際に各プロダクト毎の技術スタックをそろえた実際の効果 新しくプロジェクトにはいったオンボーディングのキャッチアップ速度が早い 1つのプロダクトを理解すると、それ以外のプロダクトはそれまでのシステム構成の差異をもと にキャッチアップできる(メンタルモデル形成の後押し) 参考： 「プログラマー脳 ～優れたプログラマーになるための認知科学に基づくアプローチ」 細かいライブラリやビジネスルールは異なるが、各プロダクトの良い部分・悪い部分が明確にわ かる 私たちのチームの例
16. 16 / 70 当初のアプリ開発メンバーはプロジェクトから外れており、保守フェーズ後も何度か担当者が変更 ソフトウェアプロダクトにおいて担当者の交代は「あるある」 例 初期開発担当者 保守フェーズ後のエンハンス開発者 運用保守担当者 担当者が変わって継続してユーザーへ価値提供を促進できるよう、情報を理解しやすい形にとどめ ておくことが必要 理由5: メンバー変更によるナレッジ不足の補強
17. 17 / 70 ただ、ビックリライトを進めるだけならソフトウェアエンジニア側からみたらにコードを書けるか らうれしい リライトはいい面だけでなくリスクも大きい リグレッションのリスク 見積もりに対する予算超過 ステークホルダーやユーザーにとってのメリットを考える必要もある リライトすることによるステークホルダーの見返りを考える 例 ビッグリライトする代わりに新機能を追加で入れる（LINEミニアプリに新機能追加） セキュリティ面が補強される最新のアーキテクチャにできる キャッシュ機構を導入しレスポンスが高速化し品質向上 理由6: 今後のビジネス価値への寄与に期待できた
18. 18 / 70 ビックリライトを決断！！
19. 19 / 70 リライトするにあたり直面した課題
20. 20 / 70 開発から保守フェーズまでの間に、メイン担当者が複数回変更 プロダクトに対する深いコンテキストが失われていた 顧客との関係性 プロダクト本当に実現したいこと プロダクトの業務ルール プロダクトを構成する特殊な環境や外部リソースの制約 課題1: コンテキストの喪失
21. 21 / 70 複数のツールにドキュメントが散らばっていたり、Wikiに大事な情報がのっていなかったり 各種ツール GitHub Wiki Backlog Slack etc… できる限りドメイン知識はソースコードをドメインモデルとして構築 ドメインモデルを読めばドメイン知識がわかるようにすることで実際に動いているコードがドキュ メントにもなる 課題2: ドキュメントの散在
22. 22 / 70 DEVやSTG環境の差異があるが、利用手順が不明なため開発には入れない 外部に依存するAPIを呼び出す際の事前のIP許可が必要で結合テストが難しい PRD Frontend (CloudFront + S3) External API STG Frontend (CloudFront + S3) External API (IP 制限あり) DEV Frontend (CloudFront + S3) Mock API 課題3: 開発環境の不整備
23. 23 / 70 テスト仕様書が存在しない テストコードも存在せず、機能の期待する結果の判断が難しかった 旧環境のアプリを触り倒して把握したり、Vue2のコードを読み込む必要があった 課題4: テストコードの欠如
24. 24 / 70 課題を解決するための取り組み
25. 25 / 70 コンテキストが喪失しているため、コードを書く前にまずはドメイン知識の理解を進めた 具体的にやったこと プロダクトを使った実際のユーザー体験（例：店舗にいってサービスを使ってみる） ドキュメントを一通りざっと読んでみる。別の開発者と不明点をディスカッションする 取り組み1: ドメイン知識を把握する時間をもつ
26. 26 / 70 取り組み2: ドキュメント整備を並行して実施
27. 27 / 70 開発初期から、開発環境と環境構築自動化にコストをかける GitHub Actionsを利用したCI/CD環境構築 ローカル環境整備（フロントエンドビルドツールのVite） 初期コストは後々になって恩恵として返ってくる 環境毎の差異や開発者毎に環境がことならないよう仕組み化しておくことで開発後もメンテナビリ ティ向上 取り組み3: 開発環境整備と自動化に時間を惜しまない
28. 28 / 70 AWS(PRD) AWS(STG) AWS(DEV) mainブランチ(GitHub) featureブランチ(GitHub) Local PC AWS(PRD) AWS(STG) AWS(DEV) mainブランチ(GitHub) featureブランチ(GitHub) Local PC DEV・STG環境へデプロイ PRD環境へデプロイ プルリクエストを作成 git push テストコード実行 コードレビュー プルリクエストをマージ プルリクエストをmainにマージ GitHub Actions ワークフローがトリガー DEV環境にデプロイ(cdk deploy) GitHub Actions ワークフローがトリガー STG環境にデプロイ(cdk deploy) デプロイ完了通知 リリースノートを作成 リリースノートをpublish GitHub Actions ワークフローがトリガー PRD環境にデプロイ デプロイ完了通知
29. 29 / 70 ビックリライトはリスクが大きい
30. 30 / 70 もう2度とビックリライトというペインを 誰にも追従させたくない！
31. 31 / 70 そうだ、そういえば
32. 32 / 70 クリーンアーキテクチャがあった！
33. 33 / 70 特定フレームワークやライブラリ依存の排除 クリーンアーキテクチャ（レイヤードアーキテクチャ）をベースに、コアなドメインロジック、ド メインモデルをライブラリやフレームワークからの依存から引き剥がす 置き換えの時に、フレームワークやライブラリに密結合した部分の大幅な書き換えをなくす 参考：Robert C.Martin「Clean Architecture 達人に学ぶソフトウェアの構造と設計」 取り組み4: クリーンアーキテクチャの採用
34. 34 / 70 フロントエンドクリーンアーキテクチャ導入解説
35. 35 / 70 クリーンアーキテクチャは、システムの関心事を分離するためにソフトウェアをレイヤーに分割す る設計手法 Robert C. Martin氏が提唱（公開ブログ：2012年8月、書籍：2017年） https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.htmlより引用 クリーンアーキテクチャとは？
36. 36 / 70 1. フレームワークに依存しない 特定のフレームワークやライブラリに依存しない フレームワークやライブラリをツールとして使用でき、システムをその制約にべったり合わせる ことは不要 つまり、フレームワークは、目的を達成するための手段の1つとしてとらえることができる 2. テスタビリティ（テスト容易性）向上 ビジネスルールはUI、データベース、Webサーバーなどの外部要素なしでテスト可能 3. UIに依存しない UIは簡単に変更可能で、ビジネスルールに影響を与えません 例として、Web UI(GUI)をコマンドラインインターフェース(CLI)に置き換えることが可能 クリーンアーテクチャで設計されたシステムの特徴
37. 37 / 70 4. 特定のデータベースに依存しない OracleやSQL ServerをMongo、BigTable、CouchDBなどのDB が変わってもアプリケーションの機能を維持できる。ビジネスルールはデータベースに依存しませ ん。 5. 外部API、外部システムに依存しない ビジネスルールは外部の世界について何も知る必要がない https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.htmlより クリーンアーテクチャで設計されたシステムの特徴
38. 38 / 70 各層の依存方向は中心に一方向 同心円は、円の中心に近づくほど抽象度レベルが上がっていく。円の外側はシステムの仕組み (詳細)、内側は方針(抽象)である。 ソースコードの依存性は、内側(上位レベルの方針)だけに向かっていなければいけない 各層の境界を越えるデータ 境界を越えるデータはシンプルなデータ構造にする。データ転送オブジェクト（DTO）などを使 用する。データベースのレコードやカラムの構造など、外部のフォーマットを内側のレイヤーに 渡すことは避ける 各層の境界を越えるときは依存関係ルールに従う 制御の流れに逆らうソースコードの依存関係を作成し、 「依存関係のルール」に従わせる（依存 性逆転の法則） 基本ルール
39. 39 / 70 Web フレームワークやデータベースなどのアーキテクチャの外部に位置するツールが古くなった場 合、それらの古くなった要素を最小限の手間で別のツールに置き換えることができる 例： Vue -> React React -> Next.js React -> Svelte DynamoDB -> MongoDB 仮にフレームワークやデータベースに結合しすぎたソフトウェアの場合、リライトや大規模なリフ ァクタリングを迫られる 私たちの場合は、今後プロダクトとして成長を維持できると考えたため、このルールに従うことを 決断 ルールに従うことで得られる恩恵
40. 40 / 70 Webは詳細（＝技術的な手段の1つ） フレームワークは詳細 APIは詳細 クリーンアーキテクチャの観点
41. 41 / 70 方針 WebフレームワークであるReactやUIのデザイン部分は、層の一番外側に配置 「ドメインルールやドメインモデル」は内側のコアロジックとして配置 このように配置することで内側に配置した外側ほど変わりにくい処理を閉じ込めて外側から の依存を減らす 依存を減らすことでWebフレームワークのトレンドやEOL、破壊的変更により環境が変わっ ても内側のロジックを守りやすい 私たちのプロダクトで適用した方針
42. 42 / 70 アルバムと写真を表示する簡易アプリ Reactベースでフロントエンドをクリーンアーキテクチャで設計 参考：https://github.com/drumnistnakano/react-clean-architecture-sample サンプルコード
43. 43 / 70 サンプルコード - アルバム画面 -
44. 44 / 70 サンプルコード - 写真画面 -
45. 45 / 70 JSONPlaceholder フェイクデータをオンラインで返してくれるREST APIサーバー サンプルコードのテストやプロトタイプ構築に活用 参考： JSONPlaceholder - Free Fake REST API 利用したAPI fetch("https://jsonplaceholder.typicode.com/albums/1/photos") .then((response) => response.json()) .then((json) => console.log(json)); [ { "albumId": 1, "id": 1, "title": "accusamus beatae ad facilis cum similique qui sunt", "url": "https://via.placeholder.com/600/92c952", "thumbnailUrl": "https://via.placeholder.com/150/92c952" }, --- 中略 --- ]
46. 46 / 70 ディレクトリ構造 . └── src ├── core // コアロジック │ ├── domain // ドメイン層 │ │ ├── entities // エンティティ定義 │ │ ├── repository // リポジトリのインターフェース定義 │ │ └── support // API Clientなどのサポート関数の定義 │ ├── infrastructure // インフラ層のインターフェース格納先 │ │ ├── api-client // API Clientの実装詳細 │ │ ├── logger // Loggerの実装詳細 │ │ └── repository // リポジトリの実装詳細 │ ├── usecase // アプリケーションユースケース層 │ └── util // Coreで利用可能なユーティリティ関数 ├── di-container // 依存注入周り │ ├── env-util.ts │ ├── register-container.ts │ └── service-id.ts └── framework // フレームワーク層 ├── cli // CLI │ ├── controllers // Usecase層への橋渡し │ └── main.ts // CLIのエントリポイント └── web // Web ├── presenters // Usecase層への橋渡し ├── EntryPoint.tsx // Webのエントリポイント ├── components // Reactのコンポーネント群
47. 47 / 70 https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.htmlより引用 再掲
48. 48 / 70 レイヤー間の関係図
49. 49 / 70 層 説明 Domain層 ドメインロジックを定義する層。ビジネスルールやエンティティを含む Infrastructure層 外部システムとのやり取りを担当。APIクライアントやデータベースアクセスを含む UseCase層 ユースケース。ドメイン層とインフラ層をつなぐ Framework層 ユーザーインターフェースを担当。Reactコンポーネントを含む レイヤー毎の定義
50. 50 / 70 その他、詳細
51. 51 / 70 "dependencies": { "@vanilla-extract/css": "1.15.3", "inversify": "6.0.2", "react": "18.3.1", "react-dom": "18.3.1", "react-lazy-load-image-component": "1.6.2", "react-router-dom": "6.25.0", "swr": "2.2.5", "zod": "3.23.8" }, "devDependencies": { "@inquirer/prompts": "5.1.2", "@types/react": "18.3.3", "@types/react-dom": "18.3.0", "@types/react-lazy-load-image-component": "^1.6.4", "@vanilla-extract/vite-plugin": "4.0.13", "@vitejs/plugin-react-swc": "3.7.0", "@vitest/coverage-v8": "2.0.3", "dotenv": "16.4.5", "typescript": "5.5.3", "vite": "5.3.4", "vite-tsconfig-paths": "4.3.2", "vitest": "2.0.3" }, 技術スタック
52. 52 / 70 Framework層にAtomicDesignのコンポーネントを配置 コンポーネント毎にvanilla-extractでデザインファイルを読み込む運用 TSの型付けができること、CSS Modulesへの移行コストが低そう、デザイナーにいただいたデザイ ンを流用しやすい Framework層にAtomicDesignのコンポーネントを内包 // photo-album/src/framework/web/components/templates/AlbumList.css.ts import { style } from "@vanilla-extract/css"; export const albumList = style({ display: "flex", flexWrap: "wrap", gap: "1rem", justifyContent: "center", padding: "1rem", }); --- 以下省略 ---
53. 53 / 70 UseCaseの戻り値をDTOに履き替えて、ドメイン層の情報がしみださないようにする DTO定義は、以下 DTOでFramework層にCoreの情報が染み出させない // photo-album/src/core/usecase/find-album-use-case-dto.ts import type { Album } from "@/core/domain/entities/album"; type AlbumInfo = { id: number; title: string; }; export class FindAlbumUseCaseResponseDto { readonly albums: AlbumInfo[]; constructor({ albums }: { albums: Album[] }) { this.albums = albums.map((album) => ({ id: album.id, title: album.title, })); } }
54. 54 / 70 DTOでFramework層にCoreの情報が染み出させない // photo-album/src/core/usecase/find-album-use-case-impl.ts export const buildFindAlbumUseCase = ({ albumRepository, logger, }: { albumRepository: AlbumRepository; logger: Logger; }): FindAlbumUseCase => { return async () => { logger.debug({ message: "use-case: find-album-use-case-impl" }); const result = await albumRepository.findAll(); --- 中略 --- return { success: true, data: new FindAlbumUseCaseResponseDto({ albums: result.data }), }; }; };
55. 55 / 70 Repository、UseCase、Domain層に対するユニットテストの実装が可能 自前で作ったダミーオブジェクトを使って、依存性注入させている テストコード導入 // photo-album/src/core/usecase/find-album-use-case-impl.small.test.ts describe("FindAlbumUseCase tests", () => { test("should return all albums on successful fetch", async () => { const findAlbumUseCase = buildFindAlbumUseCase({ albumRepository: new AlbumRepositoryDummy({ findAllReturnValue: { success: true, data: [ { userId: 1, id: 1, title: "Album 1" }, { userId: 2, id: 2, title: "Album 2" }, ], }, }), logger: new LoggerDummy(), }); const result = await findAlbumUseCase(); expect(result).toEqual({ success: true, data: { albums: [
56. 56 / 70 リライト後の変化
57. 57 / 70 SWRをいれたことによりAPIフェッチで初回は時間がかかるものの、キャッシュを利用できるよう になった SWRとTanstack Queryで実装比較したが、SWRの方がバンドルサイズが軽量なことやオプションが 少なくシンプルな実装になるためSWRを選定 SWRの導入効果 // photo-album/src/framework/web/components/templates/AlbumList.tsx export const AlbumList: React.FC<AlbumListProps> = ({ onSelectAlbum }) => { const { container } = useContext(DIContainerContext); const { data: albums, error: albumsError, isLoading: isAlbumsLoading, } = useSWR({ container }, useFetchAlbums, { suspense: true }); if (isAlbumsLoading) return <Loading />; if (albumsError) throw new Error(`loading albums: ${albumsError.message}`); return ( --- 以下省略 ---
58. 58 / 70 不十分だったドキュメントを整備したことや、テストコードを書いたことで機能開発や保守での修 正を自信を持てるようになった 保守性の向上 // photo-album/src/core/domain/entities/album.ts import { z } from "zod"; const AlbumSchema = z.object({ userId: z.number(), id: z.number(), title: z.string(), }); export type AlbumProps = z.infer<typeof AlbumSchema>; export class Album { // --- 中略 ---- /** * アルバムID * * @example 1 */ readonly id: number; // --- 中略 ---
59. 59 / 70 コード量が増えたため、レビュー負荷が上がった 頻度高くペアプロ、コードレビューで負荷を軽減 アーキテクチャ学習のチーム育成という観点からは結果的に良かった レガシーコードの改善は一人よりも二人、二人よりもチーム全員でやる 参考：レガシーソフトウェア改善ガイドより https://www.shoeisha.co.jp/book/detail/9784798145143 コード量の増加
60. 60 / 70 学んだ教訓
61. 61 / 70 リライトするときはインクリメンタルにしよう 複数ページがあるなら1つのページだけ 複数機能あるなら、機能を分解して1つだけ API呼び出しから画面描画までのシーケンスを分解して一部から 期待した動きになるか、一進一退しながら実装を進める TDDで各層ごとにテストコードを実装する。一歩一歩、終わりに向けて確実感が増す 教訓1: リライトは一気にしない
62. 62 / 70 自分で生み出したコードを何年かたって他の人がビックリライトを考案させないようにする そのために、コードを小さく保って使い捨てても書き換えが容易にしておく 最小限の部分だけ修正すれば維持できるというのが最高な状態 教訓2： ビックリライトをさせないようコードを
63. 63 / 70 プロダクトのコンテキストは当初から抜けてしまうことがしばしば 開発後に保守を最低限できるドキュメントを整備しておく GitHubのIssueやPRを、Wikiにリンクさせてまとめておくだけでも良し ドキュメントは作成だけでなく、更新もしていこう。更新する人を賞賛しよう！ 教訓3: 情報の残し方もソフトウェア開発の設計の1つ
64. 64 / 70 それは砕けた定義でいうと、 「開発者のコードが呼び出すものがライブラリで、開発者のコードを呼び出すものがフレームワー ク」 というものだ。 — 中略 — フレームワークは開発者のコードを呼び出すので、コードはフレームワークと高度な結合を作る。 ライブラリは一般的に、より汎用的なコードのため、結合の度合いは低くなる — 中略 — フレームワークはアプリケーションの基礎部分であるため、チームは積極的に更新を行わなければ ならない。 ライブラリは一般的にフレームワークよりも弱い結合点を形成するため、更新についてチームはよ りカジュアルに行うことができる 進化的アーキテクチャ「6.5.8 ライブラリのアップデートとフレームワークのアップデート」 教訓4: フレームワークは積極的更新を計画しておく
65. 65 / 70 ソフトウェアの改善は、常にユーザーや顧客のために行うことを忘れない 改善の目的は、ユーザー体験の向上やビジネス価値の最大化である 技術的な美しさや最新技術の導入だけを目的にしない しかし、最新技術にBetできる余白ももっておけるように、使い捨てできるようミニアムなソフトウ ェアを保っておく 教訓5: ソフトウェアの改善は「誰のために」を忘れずに
66. 66 / 70 さいごに
67. 67 / 70 フレームワークやライブラリをつかうと楽に早く開発できる フレームワークやライブラリのクラスやメソッドを使い込んで思いっきり結合してくれることを提 供側は望んでいるし、利用者も同様 しかし、フレームワーク依存しすぎると自分たちが意図しない方向（フロントエンドのトレンド、 EOL、破壊的変更など）で書き換えやリファクタリングが必要になってくる場合がある チームでライブラリやフレームワーク自体を統一する標準化をとるのもいいが、 ソフトウェアアーキテクチャを統一して解決する考え方もある まとめ
68. 68 / 70 Vue.js 公式: Vue 3 移行ガイド React 公式: Reactリファレンス Chris Birchall 著: レガシーソフトウェア改善ガイド Robert C. Martin 著: Clean Architecture 達人に学ぶソフトウェアの構造と設計 Neal Ford, Rebecca Parsons, Patrick Kua 著: 進化的アーキテクチャ 絶え間ない変化を支える 参考資料
69. 69 / 70
70. 70 / 70