はじめに
この記事はモチベーションクラウドシリーズアドベントカレンダー2022の記事です。
Vue2(Options API)使用しているPJTに対し、CompositionAPI化&Typescript化を始める機会がありました。
今回はそのPJT開始の初動の話をピックアップして、
①環境準備の初動
②PJT進行の初動
の2本立てでお話したいと思います。
やりたいこと
- Vue2アプリに対し
- Options APIで書かれている処理をComposition APIに書き換えたい
- TypeScriptを導入したい
環境
- Vue.js(v2)
- vue-cli
- yarn
①環境準備の初動
初動のinstallを進めます。今回導入する2点のinstallと初期設定を進行します。
- Composition API
- TypeScript
Composition APIのinstall
Vue3の推奨機能とされているComposition APIですが
Vue2でも拡張機能としてimportして使用することができます。
下記実行でinstallを進行します。
yarn add @vue/composition-api@{バージョン}
(※ バージョンに関しては都度確認してください)
TypeScriptのinstall
TypeScriptと関連ライブラリをinstallします
yarn add --dev typescript@{バージョン}
yarn add --dev @typescript-eslint/eslint-plugin@{バージョン}
yarn add --dev @typescript-eslint/parser@{バージョン}
yarn add --dev @vue/cli-plugin-typescript@{バージョン}
yarn add --dev @vue/eslint-config-typescript@{バージョン}
ts_configファイル作成
TypeScriptの設定ファイル。tsconfig.jsonを作成します。
アプリのルートディレクトリでtsconfig.jsonを作成してください
touch tsconfig.json
ts_config設定内容
tsconfig.jsonに初期設定を記述していきます。
今回のリリースはビッグバンリリースを避けて細かく行うことに決めていました。
そのため、「一部は.tsファイルに置き換えて、一部はまだ.jsファイルのまま」といった、
.js、.tsファイルが混在する期間が発生します。
このために、移行プロジェクトの観点での設定が必要です。
compilerOptions.allowJs : true
trueを立てることで、.jsファイルがビルド対象に含まれ、
.tsファイルから.jsファイルを参照ことが出来るようになります。
compilerOptions.checkJs : false
falseにすることで、.jsファイルに対して静的解析をしないようにします。
"include": [
(中略)
"src/**/*.js"
]
コンパイル対象に.jsファイルを含めます。
移行PJTが完了した暁には.jsファイルがなくなり、上記の設定は必要なくなるため
移行最後のタスクとしてtsconfg設定の更新を積んでおきましょう。
lintルール追加
.eslintrc.jsにtypescript用のlint設定を追加しましょう。
設定後、既存ファイル対しにlintの新ルールからの指摘が大量に届きます。
- 新たなlint設定で引っかかった箇所に、一時的にlint disableをつけておく
- 移行タスクや他の機能開発で対象ファイルを一緒に直しておく
という方針を固め、lint修正を都度進めることにしました。
以上で、TypeScriptとComposition APIが動く環境ができました。
②PJT進行の初動
方針の策定「小さく・続けやすく」
PJT進行を行う上で、今後の作業を鑑みたとき、まず最初に決めたのが
「小さく・続けやすい」 形でやってこう。という方針でした。
定めた理由を大きく3点で記述します。
①ユーザーへの価値提供を止めたくない
本リファクタへリソースを割きすぎてしまい、顧客への価値提供が滞ってしまった。。。
なんてことは絶対に避けなければなりません！
そのため、通常の開発業務と"並行して進行できる"事を目指しました。
②ビッグバンリリースを避けたい
影響範囲が広く、多岐に渡るため、複数のPRが重なるとすぐ試験の負荷が高くなっていきます。
負荷低く、安全なリリースを目指すために、"fatにしないで、小さく出す"事を目指しました。
③優先度・メンバーの変化に強いPJTにしたい
チーム状況に応じたメンバーの増減や入れ替えは起こりえます。
もしこのとき属人性が高い状態だと、メンバー変更と同時にPJTが停止することも有りえるので、
属人性低く、誰でも始めやすい形がいいだろうと考えていました。
また、状況に応じて機能開発の優先度が高まることもあります。他機能の優先度が高まったら、すぐシフトできるが、
お手すきの際にはこちらに着手できる、戻れるような柔軟さを持ちたいとも考えました。
このようなことから 「始めやすい」PJTを目指しました。
小さく続ける工夫
実際に定めた「小さく・続けやすく」を目指して進行するために行った工夫を2つ、ピックアップしてご紹介します。
①PJT憲章の作成
長くPJT進行を行う上で、様々なステークホルダーも増えていきます。
- PJTの価値と優先度を判断するPdM、PM、エンジニアリーダー
- 開発を実際に進行するフロントエンジニア
- チームの増減に合わせた新規ジョインメンバー
継続的にリファクタリングを続けていく上では周りの理解と協力・応援が不可欠です。
独自の観点を持ったチームメンバーと、視界を合わせて同じゴールを目指すために、
PJT概要をまとめた資料「PJT憲章」を作成して認識共有を図りました。
※ PJT憲章の書き方に関してはAsanaさんの下記の記事が参考になります
資料では先にご紹介した方針や、PJTの目的、マイルストーンを整理し、
開発フローなども追記して作成しました。
実際に、ステークホルダーが増えるタイミングでは、毎回 活用することができ、
オンボーディング負荷を下げることができました。
MTGに赴く際には話す側も要点を押さえて話すことができますし、
参加する側も事前準備や事後の見返しなどができて便利です。
②コンポーネント単位のチケット分割
今回の移行PJTは
① Options API -> Composition API化
② TypeScript化
の2点です。今回のPJTでは①、②を順にやっていくなどではなく、
各コンポーネントごとに①、②を対応していくことにしました。
これを遵守するために、対応チケットも各コンポーネント毎に作成して、タスク進行をはじめました。
コンポーネント毎に対応していくことで
「①はやったけど②はまだやってない」などの中途半端な状況を防ぐことができ
どのファイルまで対応したかはっきりする形を目指しました。
対応/未対応と影響範囲がはっきりさせることで「続けやすい」形を目指しました。
さいごに
本PJT進行に携わることで、リファクタリングとの向き合い方、闘い方を考えるきっかけになりました。
これから移行PJTを始める皆様へのヒントになると幸いです。