はじめに
こんにちは、アイスタイルでWebエンジニアをやっています、伊藤(itohis)です。
この記事は、WEBフロントエンドのフレームワーク「Nuxt」のバージョン2系から3系へのアップデート作業記録をテーマごとにパート分けしたうちのひとつです。
テーマは以下の通りで、投稿日を分けて連載形式で紹介していきます。
本日は移行を終えての振り返りについて記載します。
導入については、初回記事の①移行方針の記事をご覧ください。
12/17(水) ①移行方針
12/21(日) ②VuexからPiniaへ
12/22(月) ③実行時環境変数
12/23(火) ④【本記事】移行を終えて
移行を終えて
大変でしたが、結果なんとかなりました。
v3への移行は、ここまでの記事で触れた通り難しいポイントも多く、ほとんど書き直しのコストは確かに大きかったです。一方で、事前調査の通りに動くように持ってこれたものも多く、十分に移行は実現可能であることを示せました。
事前調査がうまくいった部分は、新しい状態管理ツール(Pinia)やCompositionAPIの書き方など、事前にある程度の学習が必要なことがわかっていたので、先行して調査してメンバーに共有できていたところだと思います。Nuxtについてはそこまで詳しいメンバーは居なかったものの、Typescript経験者は多かったのも助かりました。
振り返ってみると、レベル感を把握してチーム全体で足並みを揃えていくのが重要だったのかもしれません。
今後は、さらにv4への移行が待っていますが、こちらは破壊的な変更は少ないと聞いているので胸をなでおろしています。
バージョンアップ移行のコツ
コツはありません...が、Nuxtに関して言えば公式ドキュメントがやはり重要でした！
もっともっと言えば、公式ドキュメント内にあるビデオ解説のリンクが超重要です。
見てみたらここで重要なこと全部話していた...ということが何度もありました。
もちろん英語ですが、YouTubeはデフォルトで自動翻訳機能もついてますし、普段WEB開発をされている方なら十分に理解できるレベル感だと思います。
ついでのコラムのような内容ではなく、ガッツリ仕様解説なので、ビデオを最優先で見るべきだと感じました。
既存システムへの向き合い方
パート3でも触れた通り、フレームワークで新しい機能が実装されても、既存システムへ採用するのが難しい場合があります。経験則から、ひとつのアンチパターンとして「全部一度にやろうとしてスコープが広がりすぎる」というものがあります。
なるべく新しい機能や環境を取り入れたいものですが、油断しているとスコープは広がって、最初に目指していたゴールを見失います。なるべく小さい単位でプロジェクトや作業を終わらせてから、やりたいことを達成できるか吟味していくと、うまく回っていくはずです。今回のNuxt移行でも、これを強く意識させられました。
実際の現場では、「一番やりたかった新機能だけ諦める」ような、歯がゆい選択を迫られることもあるかと思います。そのような悩みを受け止めて達成可能な範囲を考えること、そのものに価値がありますし、何より仕事では無事にプロジェクトやタスクの完了が重要であることも多く、完璧ではない選択が結果として組織にとって正しいこともあります。
今回の記事であれば、まずは「バージョンアップの完了」が重要であり、より良い仕組みづくりや機能実装は後からでも可能だったので、妥協した場面もいくつかありました。
※ 例えばパート3の記事がそれにあたります。
このように、時には取捨選択も既存システムとの向き合う上では重要だと考えています。
さらばNuxt2...
パート1から読んでくれた方へ
おそらく必要に迫られた方かと思います。ありがとうございます。健闘を祈ります🙏
そうではない方もいらっしゃったら、そちらもありがとうございます。
今回アドカレで意気込んで記事を連投しようとサブカレンダーに登録したものの、業務時間内でなかなか間に合わず、慌てふためきながら最後の記事を書いていますが、少しでもこれらの記事がお役に立てば嬉しいです。
それでは良いクリスマスを🎅
Discussion