我在工作上維護的不是一個前端，而是好幾個：Vue 2 + Vuex 的專案、Vue 3 + Pinia 的專案，還有桌機版和手機版分開的系統。它們服務同一套業務，所以一個需求常常要改好幾次。
這是課堂上學不到的事。這篇整理我實際遇到的狀況。
同一個需求，要做好幾次
幾個真實的例子：
- 註冊姓名欄位調整：桌機版和手機版都要改。
- 登入後回到原本頁面：兩個版本各做一次。
- 圖片檔名中文改英文：每個專案都要處理。
- 無障礙修正：多個專案都要符合。
這些修改的概念相同，但實作不一定能直接複製：
| 差異 | Vue 2 專案 | Vue 3 專案 |
|---|---|---|
| 狀態管理 | Vuex | Pinia |
| UI 元件庫 | Vuetify 2 | Vuetify 3 |
| 路由 | Vue Router 3 | Vue Router 4 |
例如 404 路由，Vue Router 3 寫 path: '*'，Vue Router 4 要寫 /:pathMatch(.*)*。同樣的概念，寫法不一樣，測試也要再做一次。
最大的風險是漏改
修改次數變多，時間成本還不是最麻煩的，真正的問題是漏掉。
我自己就遇過：有一次把註冊頁的姓名拆解邏輯移除，測試也沒問題，後來才發現登入頁的補填資料表單裡還有同一段邏輯。兩個專案都是這樣。
原因很簡單：相同的邏輯在同一個專案裡就寫了兩份，專案之間又各有一份。需求單只寫「註冊」，我就只改了註冊。
我現在的做法
動手前先搜尋
改之前先在每個專案搜尋相同的函式和關鍵字，確認影響範圍：
grep -rn "splitName" src
只改眼前這一支檔案，是最容易漏的做法。
用 Notion 列出專案功能清單
發生過漏改之後，我開始用 Notion 把每個專案的功能列成清單，例如註冊、登入、補填資料、會員資料。
有需求時先對照清單，看看哪些功能會受影響；測試時再照著清單一項一項走過。這樣姓名這類改動，就不會只測到註冊頁，登入頁的補填資料表單也會在測試範圍裡。
清單要隨著功能更新才有用。新增功能時順手補上，它就是一份不靠記憶的測試範圍。
一次改完
同一個需求盡量同一天處理完所有專案。隔太久，就會忘記當時的上下文，也更容易出現版本不一致。
什麼時候該抽成共用模組
看到重複，第一個想法通常是抽成共用套件。但我現在不會馬上這麼做。
適合抽出來的：
- 不依賴框架的純邏輯，例如日期格式、資料驗證。
- 真的完全相同，而且會一起改的規則。
- 像日期選擇器的鍵盤操作這種，同專案內多個頁面共用的邏輯，就可以先抽成 mixin 或 composable。
不適合馬上抽的：
- 綁定 UI 元件庫的畫面，Vuetify 2 和 3 差異很大。
- 只是目前長得像，但各自的需求會往不同方向發展。
共用模組也有成本：要處理版本、發布，改一個地方可能影響所有專案。Vue 2 和 Vue 3 要共用元件，更是不容易。
我的判斷方式是：先在專案內抽出來，確認它穩定，而且真的在多處一起變動，才考慮跨專案共用。
這次學到的事
- 維護多個專案時，「知道要改哪裡」比「怎麼改」更花時間。
- 搜尋是最便宜的防護。
- 重複程式碼不一定要立刻消除，錯誤的抽象比重複更難維護。
- 需求單寫的範圍不一定等於實際影響的範圍。