どうも〜、エージェンシー事業のエンジニアチームでユニットマネージャーをしていますぬまちゃんです！
前回はAWS AuroraからGoogle CloudのDatastreamを用いてBigQueryへデータをレプリケーションした話
をしました。
今回は打って変わってフロントエンドのお話をしようと思います！
背景・きっかけ
自分が担当しているサービスではフロントエンドにReactを採用していて、UIフレームワークにはMUI(Material-UI)を使っています。
MUIが現行のメインバージョン(v5)になったのは2021年9月でした。
その頃はMUIのバージョンアップ作業よりも優先度の高い開発案件があったり、アップデートの作業量が多いこともあり放置してしまっていました。
そんなこんなで3年ほど放置していたのですが、Reactのメジャーバージョンを上げる作業でMUIのバージョンを上げないと進められない事象が発生しました。
ここでようやく重い腰が上がり、アップデート作業をすることにしました。
話を始める前に
自分が担当しているチームでは以下の記事にもある「改善Day」を設定していて、毎週月曜日に改善活動を行うようにしています。
今回のバージョンアップはこの施策をガッツリ使って改善に努めました！
アップデート作業の概要
以下がアップデート前のMUIのバージョンで
@material-ui/core: 4.12.4 @material-ui/icons: 4.11.3 @material-ui/pickers: 3.3.11 @material-ui/lab: 4.0.0-alpha.61
以下がアップデート後のMUIのバージョンです（2024年3月時点）。
@mui/styles: 5.15.10 @mui/material: 5.15.10 @mui/icons-material: 5.15.10 @mui/x-date-pickers: 6.19.4 @mui/lab: 5.0.0-alpha.165
基本的なアップデートは下記のコマンドを実行するだけで完了します。
import 文やデフォルトプロパティの設定も全て自動で挿入してくれます。
npx @mui/codemod v5.0.0/preset-safe <path>
その後は、コマンドで修正できない箇所をアップグレードガイドに沿って手動で変更していく作業になります。
実際の作業は Migrating to v5 - Material UI を見た方が詳細でわかりやすいので省略します。
大変だったこと
アップデート作業を進める中で大変だったことが大きく２点あるので順に説明していきます。
■ 開発案件と並行して作業をしなければならなかった点
アップデート作業を本格的に始めたのは2023年12月ごろからでした。
始めた頃にはもうすでに次の四半期で実施する案件の準備をしていて、かつその案件の優先度はそれなりに高いものでした。
なので、最初から開発案件とMUIのアップデート作業は並行して進めないといけない状態ではありました。
実際に並行して作業を進めた感想としては、並行で進めるのは現実的ではないと感じました。
案件で開発したフロントエンドの差分を毎回取り込んで、そのコンポーネントに対してアップデートを適用しなければならない、という状況でした。
1ヶ月を過ぎたあたりで「このイタチごっこを続けてはいけない」と思い、開発案件が落ち着いたタイミングを見てフロントエンドの開発を一時停止する判断をしました。
■ 見た目の確認
担当プロダクトは約20画面以上あり、見た目が似ているものの、構成しているコンポーネントはそれぞれ別に定義されていました。
約350個のコンポーネントが定義されていたのですが、 そのほとんどがMUIのコンポーネントを直接呼び出して使っていました。
なので、その全てがアップデートの対象になっていました。
また、このアップデートでWAI-ARIAロールが改善され、DOMのマシンリーダブルさが大幅に向上していました。
しかし、v4時点のWAI-ARIAロールを指定してTesting Libraryを用いたUIテストを書いていたこともあり、テストが数十個ほど失敗していました。
「ラベルが〇〇のテキストフィールドがあり、□□□が入力されている」みたいなテストがほとんどなので修正方法はすごく単調でしたが数がとても多かったです。
総じて、見た目の変更数とテストの修正の多さが相まって目視による確認をしなければならず、とても苦労しました。
学び
今回のアップデート作業で得た学びを書きます。
あくまで私自身が感じた学びで「自分は次はこうしよう」みたいなものです。
■ バージョンアップは放置しない
3年間も放置したのは大きな失敗でした。 機能追加やUIの変更によるコンポーネント数の増加で、当初と比べると作業量が何倍も増えてしまいました。
逆に、継続的な改善をすることで以下のような良いことがあります
- 新しくて便利な機能が使える
- 上記の機能が使えることによる開発パフォーマンスの向上も図れる
- 脆弱性の対応になる
- 古いドキュメントを探さずにすむ
■ 案件と大きめの改善を並行しない
もちろん案件と改善の両方を継続的に行える方が良いですが、そう簡単に進められないことも事実だと思います。
今回は随時アップデートできるものではなかったので、案件をもう少し早めに止める決断をした方が両方ともスムーズに進んだのかなと思いました。
■ コンポーネントの共通化をする
これまで、担当プロダクトにおいてコンポーネントの共通化は最低限しか行ってませんでした。
当初は「画面が違うのだからUIや機能が同じでも別のコンポーネントである」と考えてそれぞれ定義してきました。
なので、フロントエンドのコードには同じ見た目同じ機能のコンポーネントの定義がかなり重複しています。
このまま扱う画面数が多くなると比例して定義されるコンポーネント数も増えてしまうため、この段階で共通化を進めるべきだと判断しました。
しかし、何でもかんでも共通化するべきだとは考えていません。適切な粒度で共通化するべきだと思います。
まとめ
放置してしまった結果規模の大きなアップデート作業にはなってしまいましたが、完了してよかったと思っています。
そして、「バージョンアップを放置せず継続的にアップデートしてビックバンリリースを避ける！」を肝に銘じたいと思います。
では！
