はじめに
こんにちは、株式会社Mediiの渡辺です。
以前、弊社の「Medii Eコンサル」のAPIをリプレイスした際の記事を書きました。
実は並行してフロントエンドのリプレイスもしていたので、今回はその話をします。
APIリプレイスについてはこちら
リプレイスに至った背景
APIのリプレイスとほぼ同様に、技術負債が無視できなくなったことが背景にあります。
特に大きな要因として、Vue 2のサポート切れが迫っていたことが挙げられます。
リプレイス前後の構成
リプレイス前のフロントエンドは、Vue 2/JavaScriptで構築されていました。
リプレイス後は、React/Next.js/TypeScriptにしました。
当時の課題とリプレイス理由
リプレイス前の課題
1. 採用技術
- Vue 2のサポート切れ: 2023年末にサポート終了予定
- JavaScript: 型がないことで開発効率が低下
2. コード品質
- テストが一切書かれていない: 品質を担保する手段がなく、変更時のリスクが高い
- 重複したコンポーネント: 同じようなコンポーネントが複数存在し、保守性が低下
- どこに影響するかわからないCSS: 想定外のコンポーネントに影響が及ぶ
3. Opsの未整備
- デプロイのリスク: 各開発者の端末からローカルコードベースでデプロイ
- CI/CD環境が未整備: テストがないうえ、ビルドが成功する保証もない
今の構成にした理由
Reactを選んだ理由 (なぜVue 3ではなくReactなのか)
- 採用市場: トレンド的にReactの経験者が多い
- TypeScriptの採用: 型があることで開発効率が向上
- エコシステムの豊富さ: 要件に合ったライブラリを選びやすく、情報も豊富
- 社内のReactエンジニアのスキル: 既存のエンジニアがReactを使える
リプレイスの実施
リプレイスの基本方針はAPIとほぼ同様で、段階的にリプレイスを進めること、テストコードを書くことを重視しました。
過渡期には、VueのページとReactのページを共存させながら、ページ単位でリプレイスを進めました。
実際に行ったこと
CloudFrontでパスパターンによってオリジンを振り分けるビヘイビアを設定しました。
これにより、リプレイスが完了したページから順次切り替えていきます。
CloudFrontで転送先を設定するビヘイビア
フロントエンドも段階的にリプレイスを行ったため、機能開発をほとんど止めることなく進められました。
デメリット/詰まったこと
-
パフォーマンス: ReactとVueの切り替え時にページ全体のリロードが発生
- 一定期間は許容してもらうしかなかった
- 幸い致命的なパフォーマンス問題は発生しなかった
-
ルーティングのミス: パスパターンの設定ミスにより、期待したページにリダイレクトされないことが発生
- 一度だけ、リプレイス前のReactページにユーザーがアクセスできてしまった
-
CloudFrontのクォータ: ビヘイビアの数に制限があり、リプレイスページ数が増えると制限に達した
- サポートに依頼することで即日制限の引き上げが可能だった
- CloudFrontクォータ
リプレイス期間
計画開始から完了まで約1年かかりました。
- 2022年12月: 計画開始
- 2023年5月: 初回のリプレイスページをリリース
- 2023年12月: 全ページのリプレイスが完了 (ギリギリサポート期限に間に合った！)
約1年前のことなので、記憶が美化されているかもしれませんが、大きな不具合もなくリプレイスを完了できました。
まとめ
Reactへの移行自体も意義がありましたが、TypeScriptの対応とテストコードの充実が特に大きな成果でした。
詳細は省略しましたが、デザイナーと協力してコンポーネントを再設計したことで、再利用性が向上しました。
APIリプレイスと並行で進めるのは非常にタフな作業でしたが、このタイミングで一気にリプレイスをやりきったことが、現在の開発に大きな好影響を与えています。
(おまけ) リプレイス後にやったこと
2024年はStoryBookとChromaticを導入し、デザイナーとのコミュニケーションやUIのリグレッションテストに活用しています。
より良い開発体制を目指し、引き続き改善を進めていきます。
Discussion