基於誠信真實痛點的公司專案不能公開，只能重新打造可用的環境

前兩天，我們先把大型 Vue 專案裡那些「真的會痛」的問題整理出來。

首頁 Loading 很慢、Table 一多就開始卡、Form 輸入出現延遲、Component 越拆越難維護，甚至 Composable 拆到最後，連資料到底從哪裡流進來都很難追。

這些問題，過去都遇過，現在支援其他專案還是會遇到！！！

只是現在我遇到一個更現實的問題，因為問題發生在公司的專案裡，我要怎麼把它拿出來驗證？

誠信為本！公司的程式碼不能公開，畢竟裡面有商業邏輯、內部 API、資料結構，包含使用者資料，所以要回答 Vue 新版本，到底改善了多少真實世界的痛點 ，絕對不能直接把公司的專案搬出來，所以現在我們需要重新建立一個「可以公開、可以重現、可以測量」的環境，這就是 Vue Pain Validation Lab 的開始。

需要的不是 Demo，而是一座 Lab

一開始在六角學院轉職學 Vue3 option API 到看「重新認識Vue.js：008天絕對看不完的Vue.js 3指南」學 composition API，幾乎是從 Todo、Shopping Cart 開始，然而這些專案是在練習輸出 Vue 要怎麼使用，不過這次的問題是 當 Vue 遇到真正的工程問題時，它到底花了多少成本？

所以這個 Lab 以經歷過的開發痛點起步，整個思路可以簡化成：

真實痛點
   ↓
Scenario
   ↓
Reproduce
   ↓
Measure
   ↓
Compare
   ↓
找出真正的瓶頸

我不是 Vue 研發團隊，只是一個市場使用者，所以我的目標是透過過去 PM 經驗用 PDCA，把一個模糊的「很慢」，變成一個可以被重複測量的問題。

第一件事：先把實驗環境固定下來

因此我先建立一個乾淨的 Vue 專案，作為後續所有實驗的共同基礎。

Vue
Vite
TypeScript
Pinia
Vue Router
Tailwind CSS

建立專案：

pnpm create vue@latest vue-pain-lab

再加入 Tailwind CSS：

pnpm add tailwindcss @tailwindcss/vite

這些技術本身不是研究重點，真正重要的是 所有 Scenario 都要在同一個環境裡跑。 因為未來要比較的可能是 Vue 3.5 vs Vue 3.6，如果其他條件一直變動，那最後看到的差異，就很難知道到底是 Vue 造成的，還是環境造成的。

Scenario 才是這個 Lab 的核心

一般 Vue 專案通常會從 Page → Component → Composable → Store 開始設計，但是我們要做的是不是專案，而是一個未來也可以重複使用的 Lab，所以把自己的顧慮跟 ChatGPT、Gemini、Claude 討論後，決定把 Scenario 放在最上層。

Vue Pain Lab
│
├── Scenario
│   ├── Home Loading
│   ├── Huge Table
│   ├── Reactive Chain
│   ├── Component Storm
│   └── Composable Chaos
│
├── Components
├── Composables
├── Stores
└── Benchmarks

因為對這個研究來說 Scenario 就是實驗單位，例如：Home Loading 不只是放一個 Vue Component，它會包含這個問題所需要的全部東西：

Home Loading
│
├── Page
├── Mock API
├── Data Generator
└── Benchmark

這樣未來即使換 Vue 版本，只需要重新執行同一個 Scenario，不用再重新做一個 App。

Lab 不是讓問題消失，而是讓問題可以被重現

我們說 10,000 筆資料的 Table 很卡！

「卡」是一種感受，感受要變成「可量化」，所以我們需要把它變成：

10,000 rows
      ↓
Click Sort
      ↓
Vue Update
      ↓
Measure

這時候「很卡」才開始變成可以比較的東西。

同樣地，首頁很慢，可以變成：

Load Page
   ↓
Create Components
   ↓
Reactive Updates
   ↓
Browser Rendering
   ↓
Measure

Scenario 的工作，就是把真實痛點固定下來。

開始前，每個 Scenario 需要遵守三個規則

1. 問題優先，而不是功能優先

一般 App 會想：我要做一個 Table → 設計 Component → 完成 Page

Lab 則反過來：我想驗證大量資料更新的成本 → 建立 Scenario → 設計最小可重現環境 → 開始測量

所以解決問題就是產出一個 想要知道 10,000 筆資料更新時，成本到底發生在哪裡 的產物。

2. 每次實驗都必須可以重跑

如果今天跑的是 Vue 3.5，明天換成 Vue 3.6，Scenario 卻偷偷改了資料量、操作流程或程式結構，那比較就失去意義了。

所以每個實驗都要固定，只有這樣 版本之間的差異，才有資格被拿來討論。

Scenario
   │
   ├── Dataset
   ├── User Action
   ├── Environment
   └── Measurement

3. 保留「真實開發」的味道

其實一直在想要不要用極端數字，或跑無限迴圈把它做成一個只會讓 CPU 跑滿的 Benchmark。

while (true) {
  update()
}

這種測試數字可能很漂亮，但跟真正的產品問題沒有太大關係。規劃很多天後，也決定既然要做了，就希望 Scenario 可以長得像我們每天開發會遇到的東西：

Dashboard
Table
Form
Landing Page
SPA Navigation

因為最終想要的是 這個 Framework 的改變，對工程師每天遇到的問題到底有沒有幫助？，不然利益出發的老闆們怎麼會買單呢？

o.O 先自清一下，我真的不是來拆台的！我只是來面對自己，解決問題！真的！

接著，我需要一個入口

專案架構思考很久，因為痛點很多，但是按照目前規劃，Lab 不會直接把某個 Scenario 當首頁，就算是 Home Loading scenario 當首頁也不對，因為他自己就是問題，最後拍板定案，讓首頁本身就是一個 Dashboard。

也就是 未來所有 Scenario 都從同一個 Lab 進入，這樣一來，就算換 Vue 版本時，我們不用換一套測試。

┌─────────────────────────────────────┐
│         Vue Runtime Lab             │
│                                     │
│  Scenarios                          │
│                                     │
│  [ Home Loading ]                   │
│  [ Huge Table ]                     │
│  [ Reactive Chain ]                 │
│  [ Component Storm ]                │
│  [ Composable Chaos ]               │
│                                     │
│  Environment                        │
│  Vue 3.5                            │
│  Chrome                             │
└─────────────────────────────────────┘

只需要：

Vue 3.5
   ↓
Run Scenario
   ↓
Record

Vue 3.6
   ↓
Run 同一個 Scenario
   ↓
Record

這才有辦法做真正的比較。

第一個 Baseline，先從瀏覽器開始

PDCA 最後一步就是要知道所謂的 「慢」，到底慢在哪裡？「快」，加速多少？ 總要有一個具體性的量測分析 (Analysis) 工具吧！

接下來要先建立 Baseline，打開 Chrome DevTools 的 Performance，記錄一次完整操作：

Reload
  ↓
等待頁面完成
  ↓
Stop Recording

接著先看最基本的成本分布：

Loading
   ↓
Scripting
   ↓
Rendering
   ↓
Painting

這一步看似簡單，卻讓整個研究開始有了共同語言。

因為接下來看到「慢」的時候，可以很有憑有據發問找原因，是 Network？還是 JavaScript？還是 Vue Runtime？還是 Rendering？甚至是 Browser Layout / Paint？至少，不用再說就「感覺」Vue 很慢！

今天真正建立的，其實不是一個 Vue 專案

回頭看，今天做的事情好像只是：

建立 Vue
+
加入 Vite / Tailwind
+
建立 Router
+
建立 Scenario
+
建立 Dashboard

但真正重要的改變是 開始把「感覺很慢」變成一個可以被驗證的工程問題。

專案有了，Baseline 也有了，下一篇，就開始驗了嗎？沒這麼快，因為前面提到的 CDP 只是雛形，為了實驗的公平性，明天要思考怎麼定義 Validation Rule！