電商儀表板文檔

主題

Mock ROI 分析方法論開發筆記 ​

開發日期: 2025-08-31
開發者學習記錄

概述 ​

這是一個關於如何建立 Mock 技術債務自動化分析和 ROI 評估體系的完整開發筆記。記錄了從問題識別到解決方案實現的完整思考過程和技術決策。

問題起源與動機 ​

初始問題陳述 ​

用戶提出：「要不要重新檢視一下目前測試中有哪些Mock技術，哪些是優秀的，哪些需要修正，如果是過度複雜且不符合價值比例的就必須要進行良好的trade-off」

問題分析深度 ​

這個看似簡單的問題實際上包含了多個維度：

  1. 現況盤點: 需要系統性掃描所有測試檔案的 Mock 使用狀況
  2. 品質評估: 需要客觀標準區分「優秀」vs「需要修正」的 Mock
  3. 價值判斷: 需要量化「價值比例」的概念
  4. 策略制定: 需要「良好的 trade-off」決策框架

🧠 解決方法論設計 ​

第一步：將主觀問題轉化為客觀問題 ​

原始思路：直觀檢查 ​

  • 手動檢查每個測試檔案
  • 憑經驗判斷 Mock 複雜度
  • 問題: 主觀性強、不可量化、無法複製

突破思路：量化分析 ​

  • 建立 Mock 複雜度評分算法
  • 自動化掃描所有測試檔案
  • 基於數據制定客觀策略

第二步：ROI 框架設計 ​

ROI 公式定義 ​

ROI = (修復價值 - 修復成本) / 修復成本 × 100%

其中：
修復價值 = 測試穩定性提升 + 維護成本節省 + 開發效率提升
修復成本 = 重構時間 + 學習成本 + 替代方案實施成本

評分標準設立 ​

  • 🟢 高ROI (>100%): 立即執行
  • 🟡 中ROI (30-100%): 短期規劃
  • 🔴 低ROI (<30%): 戰略性放棄或替代方案

技術實現歷程 ​

Phase 1: Mock 複雜度分析引擎 ​

核心算法設計思路 ​

typescript
calculateComplexityScore(metrics: {
  totalLines: number
  mockLines: number
  mockBlocks: number
  uiMockCount: number
  composableMockCount: number
  serviceMockCount: number
}): number {
  // 基礎分數：Mock行數佔比 (40% 權重)
  const mockRatio = (mockLines / Math.max(totalLines, 1)) * 100
  let score = mockRatio * 0.4

  // Mock block 數量懲罰 (最多30分)
  score += Math.min(mockBlocks * 5, 30)

  // UI Mock 重懲罰 (技術債務主要來源)
  score += uiMockCount * 8

  // Composable Mock 中度懲罰
  score += composableMockCount * 3

  // Service Mock 輕度懲罰 (通常是好的)
  score += serviceMockCount * 1

  return Math.min(Math.round(score), 100)
}

權重設計理由 ​

  1. UI Mock 高權重 (8分):
    • 技術債務主要來源
    • 維護成本極高
    • 容易過時
  2. Composable Mock 中權重 (3分):
    • 業務邏輯相關
    • 有一定維護價值
  3. Service Mock 低權重 (1分):
    • 通常是好的實踐
    • API 層面的 Mock 相對穩定

Phase 2: 自動化掃描系統 ​

技術挑戰與解決 ​

問題1: ESM/CommonJS 兼容性

錯誤: ReferenceError: require is not defined in ES module scope

解決方案: 創建 JavaScript (.cjs) 和 TypeScript (.ts) 雙版本

  • .cjs 版本用於立即執行
  • .ts 版本用於型別安全和 IDE 支援

問題2: 模組路徑解析

錯誤: Cannot find package 'ts-node'

解決方案: 簡化為純 JavaScript 實現，避免複雜的 TypeScript 執行時依賴

掃描策略設計 ​

typescript
// 識別不同類型的 Mock
const MOCK_PATTERNS = {
  uiMock: [
    /vi\.mock\(['"`]@\/components\/ui\//,
    /template:\s*['"`].*<[^>]+>.*['"`]/,
  ],
  composableMock: [
    /vi\.mock\(['"`]@\/composables\//,
    /vi\.mock\(['"`]vue['"`]/,
  ],
  serviceMock: [
    /vi\.mock\(['"`]@\/api\//,
    /vi\.mock\(['"`]@\/lib\//,
  ]
}

Phase 3: 標準化工廠系統 ​

設計思路：從分析到解決 ​

發現問題後，不只是報告問題，還要提供解決方案：

typescript
// ❌ 原始複雜方式
vi.mock('@/components/ui/button', () => ({...}))
vi.mock('@/components/ui/badge', () => ({...}))
// ... 還有 30+ 行

// ✅ 標準化方式
const mountOptions = createNotificationTestEnvironment()

工廠模式架構 ​

ComponentTestFactoryManager
├── ChartComponentTestFactory      # 圖表組件
├── DataTableComponentTestFactory  # 表格組件
├── FormComponentTestFactory       # 表單組件
├── ViewComponentTestFactory       # 視圖組件
└── NotificationComponentTestFactory # 通知組件 (新增)

實戰驗證過程 ​

實例 1: NotificationCard 重構 ​

原始狀況: 163 行代碼，60+ 行 Mock 設置，9 個 UI Mock 重構結果: 45 行代碼，1 行 Mock 設置 改善幅度: 72% 代碼減少

重構前後對比 ​

typescript
// ❌ 重構前 (複雜版本)
vi.mock('vue-router', () => ({ /* 15 行 */ }))
vi.mock('@/components/ui/button', () => ({ /* 8 行 */ }))
vi.mock('@/components/ui/badge', () => ({ /* 6 行 */ }))
// ... 還有 6 個類似的 Mock

const createWrapper = (props = {}) => {
  return mount(NotificationCard, {
    props: { notification: mockNotification, ...props },
    global: { /* 15 行配置 */ }
  })
}

// ✅ 重構後 (標準化版本)
const mountOptions = createNotificationTestEnvironment({
  notification: mockDataGenerators.notification()
})
const wrapper = mount(NotificationCard, mountOptions)

實例 2: RoleUsersView 整合測試優化 ​

ROI 計算: 150% (低成本 3-4 工時，高價值業務關鍵功能) 原始狀況: 257 行代碼，10 個手動 UI Mock 重構結果: 150 行代碼，0 個手動 Mock，新增 2 個測試案例 改善幅度: 40% 代碼減少 + 測試覆蓋率提升

關鍵洞察與學習 ​

洞察 1: 量化分析的威力 ​

發現: 「感覺複雜」vs「實際複雜」可能差異很大

  • NotificationList.test.ts: 144 行 Mock，37 個 UI Mock (量化後證實確實過度複雜)
  • RoleUsersView: 29 行 Mock，但 ROI 150% (感覺普通，實際高價值)

學習: 客觀量化分析勝過主觀經驗判斷

洞察 2: ROI 導向策略的有效性 ​

發現: 不是所有問題都值得解決

  • 高 ROI 項目: 立即執行，快速獲得回報
  • 低 ROI 項目: 戰略性放棄，投資更有價值的領域

學習: 資源有限，必須聚焦最高價值的改善項目

洞察 3: 標準化的复利效應 ​

發現: 標準化工具的價值會隨時間複利成長

  • 第一次使用: 節省 1 小時
  • 第十次使用: 節省 10 小時
  • 團隊推廣: 節省 100+ 小時

學習: 投資標準化工具比一次性修復更有長期價值

洞察 4: 技術債務的層次性 ​

發現: 不是所有技術債務都在同一層次

  • 表面技術債務: 重複代碼、命名不規範 (容易修復)
  • 結構技術債務: Mock 複雜度、測試策略 (需要系統性方法)
  • 架構技術債務: 系統設計問題 (需要重構)

學習: 不同層次的技術債務需要不同的解決策略

🔄 迭代改進過程 ​

第一版: 簡單分類 ​

  • 只區分「複雜」vs「簡單」
  • 主觀判斷標準
  • 問題: 不夠精確，缺乏行動指引

第二版: 量化評分 ​

  • 建立 0-100 分的複雜度評分
  • 自動化掃描工具
  • 改進: 客觀量化，可重複執行

第三版: ROI 分析 ​

  • 加入修復成本和價值評估
  • 建立優先級排序
  • 突破: 從技術問題轉化為商業決策

第四版: 解決方案整合 ​

  • 不只分析問題，還提供工具
  • 標準化工廠和使用指引
  • 完善: 形成完整的問題解決體系

技術決策記錄 ​

決策1: 算法權重設計 ​

考量因素:

  • UI Mock 維護成本最高 → 給予最高權重 (8分)
  • Service Mock 通常穩定 → 給予最低權重 (1分)
  • 總分控制在 100 分以內 → 使用 Math.min()

驗證方法: 用已知的高複雜度檔案測試算法準確性

決策2: 雙版本腳本策略 ​

問題: TypeScript 執行環境複雜性 方案A: 只提供 TypeScript 版本 方案B: 只提供 JavaScript 版本
選擇: 雙版本策略 理由: TypeScript 提供型別安全，JavaScript 提供執行便利性

決策3: 工廠模式 vs Helper 函數 ​

問題: 如何組織標準化 Mock 代碼 方案A: 簡單的 Helper 函數 方案B: 完整的工廠模式 選擇: 工廠模式 理由:

  • 可擴展性更好
  • 類型安全更完整
  • 符合開放封閉原則

決策4: 文檔詳細程度 ​

問題: 文檔應該多詳細 方案A: 簡要說明 方案B: 詳細教程 選擇: 詳細教程 (300+ 行) 理由:

  • 新團隊成員需要完整指引
  • 複雜主題需要充分解釋
  • 投資文檔品質有長期回報

📈 方法論的可複製性 ​

核心流程抽象 ​

1. 問題量化 → 建立客觀評估標準
2. 數據收集 → 自動化掃描工具
3. ROI 分析 → 成本效益評估
4. 解決方案 → 標準化工具建立
5. 實戰驗證 → 具體案例修復
6. 知識固化 → 文檔和流程建立

適用場景識別 ​

這個方法論可以應用到：

  • 代碼品質問題: 重複代碼、命名規範、架構債務
  • 效能問題: 慢查詢、記憶體洩漏、打包體積
  • 安全性問題: 漏洞掃描、權限檢查、輸入驗證
  • 用戶體驗問題: 載入時間、錯誤處理、互動流程

移植要點 ​

  1. 評估標準客觀化: 將主觀感受轉化為可測量指標
  2. 自動化工具建立: 減少人工判斷的主觀性和工作量
  3. ROI 框架應用: 確保改善項目的投資報酬率
  4. 解決方案標準化: 不只發現問題，還要提供可重複使用的解決方案

核心成功要素總結 ​

1. 數據驅動決策 ​

  • 量化勝過直覺: 用數據說話，避免主觀偏見
  • 持續監控: 建立自動化監控，及時發現回退

2. ROI 導向思維 ​

  • 價值排序: 優先處理高價值、低成本的項目
  • 資源聚焦: 避免過度分散，集中力量解決核心問題

3. 系統性解決方案 ​

  • 不只分析，還要行動: 提供具體的解決工具和方法
  • 標準化推廣: 將一次性解決方案轉化為可重複模式

4. 持續改善文化 ​

  • 迭代優化: 方法論本身也需要持續改善
  • 知識分享: 將經驗固化為文檔，讓團隊共同受益

🔮 未來發展方向 ​

短期擴展 (1-2 個月) ​

  • 其他技術債務類型: 將方法論應用到效能、安全性等領域
  • 自動化程度提升: 更智能的問題識別和修復建議
  • 團隊工作流整合: 將分析工具整合到 CI/CD 流程

中期發展 (3-6 個月) ​

  • 跨專案應用: 將工具和方法論推廣到其他專案
  • 機器學習輔助: 基於歷史數據預測技術債務風險
  • 可視化儀表板: 建立技術債務監控儀表板

長期願景 (6-12 個月) ​

  • 企業級平台: 建立完整的技術債務管理平台
  • 最佳實踐庫: 累積大量成功案例和解決方案
  • 開源貢獻: 將方法論和工具開源，服務更廣泛的開發社群

相關學習資源 ​

延伸閱讀 ​

  • 技術債務管理: Ward Cunningham 的技術債務理論
  • ROI 分析: 軟體開發投資報酬率計算方法
  • 自動化測試: Martin Fowler 的測試金字塔理論
  • 代碼品質: Clean Code 和重構技術

工具和技術 ​

  • 靜態分析: ESLint、SonarQube 等代碼品質工具
  • 測試工具: Jest/Vitest Mock 技術和最佳實踐
  • 自動化工具: Node.js 文件系統操作和正規表達式
  • 數據可視化: 分析結果呈現和報告生成

🎉 專案回顧與反思 ​

最滿意的部分 ​

  1. 問題轉化: 成功將模糊的「檢視Mock技術」轉化為具體的分析和改善行動
  2. 工具建立: 創建了可重複使用、可擴展的自動化分析工具
  3. 實戰驗證: 通過具體案例證明了方法論的有效性
  4. 知識固化: 建立了完整的文檔體系，確保知識可以傳承

可改進的地方 ​

  1. 算法精度: 複雜度評分算法還可以更精確，考慮更多因素
  2. UI 改善: 分析工具的輸出可以更加用戶友好
  3. 集成程度: 與現有開發工作流的集成還可以更緊密
  4. 性能優化: 大型專案的掃描效率還有提升空間

意外收穫 ​

  1. 方法論價值: 發現這套方法論的適用範圍比預期更廣
  2. 團隊影響: 量化分析的方式改變了團隊對技術債務的思考方式
  3. 工具復用: 建立的工具和模式在後續開發中被頻繁使用
  4. 學習深度: 深入理解了 Mock 技術的本質和最佳實踐

關鍵學習要點 ​

  1. 量化分析勝過直覺判斷 - 建立客觀標準，用數據驅動決策
  2. ROI 思維至關重要 - 資源有限，必須聚焦最高價值項目
  3. 標準化工具有複利效應 - 投資工具建立，長期收益巨大
  4. 完整解決方案比單點修復更有價值 - 系統性方法勝過零散改善
  5. 持續改善需要方法論支撐 - 可複製的流程確保持續成功

這個專案不只是解決了 Mock 技術債務問題，更重要的是建立了一套可複製、可擴展的技術債務管理方法論。這種方法論的價值將在未來的專案中持續顯現。

這份筆記記錄了完整的思考過程和技術決策，希望能為未來類似的技術改善專案提供參考和啟發。