如果比較方式不公平，Scenario 再漂亮也沒有意義
昨天，我們把大型 Vue 專案的痛點做成了六個 Scenario，但是現在有一個問題：如果 Vue 3.6 發布，我們直接升級 pnpm update vue，然後重新跑一次，然後看到以下數據開心的說 Vue 3.6 比 Vue 3.5，你們接受嗎？
| Version | Vue 3.5 | Vue 3.6 |
|---|---|---|
| FPS | 45 | 60 |
說真的，這個結論讓我很開心也有點心虛！
因為這兩次測試之間，會不會還有我們不知道的東西可以偷偷被改變？所以數字漂亮比 數據差異，真的來自 Vue 嗎？ 重要，也才是今天要解決的問題。
測試結果變快
│
┌────────────┼────────────┐
↓ ↓ ↓
Vue 版本 Browser 測試資料
│ │ │
3.5 → 3.6 Chrome 更新 10K → 5K
│
└──── 還可能有 ────┐
↓
操作流程 / OS
Vue Pain Lab 和一般 Benchmark 最大的差異是一般 Benchmark 會比大小比快慢，但是 Lab 主訴求是找原因！如果昨天建立的是 Reactive Chain Hell ，那今天應該問的是：
Vue 3.6，有沒有改善 Reactive Chain Hell？
Vue 3.5
│
│ 10000 operations
↓
Result
VS
Vue 3.6
│
│ 10000 operations
↓
Result
化學實驗裡，有一個很基本的概念 一次只改變一個變因。
Vue Pain Lab 也一樣，如果我們要比較 Vue 3.5 與 Vue 3.6，那麼 Vue 版本就是唯一應該改變的東西，其他條件全部固定。
簡單來說，我們可以把整個實驗想成兩條完全平行的跑道。
Reactive Chain Scenario
│
┌──────────┴──────────┐
│ │
Vue 3.5 Vue 3.6
Baseline Experiment
│ │
│ │
同一台電腦 同一台電腦
同一 Browser 同一 Browser
同一份資料 同一份資料
同一操作 同一操作
│ │
└──────────┬──────────┘
↓
Compare Evidence
唯一不同的只有 Vue 版本，這才有機會把差異歸因到 Vue。
Vue 3.5 ←──────────────→ Vue 3.6
↑
Only variable
這時候我們把規則定下來。
其實環境很重要，以前做任何實驗都會被要求記錄溫濕度，甚至當下心情，因為會影響結果的都要記錄，不然是好是壞原因很難找！
這次也是一樣，我們不要今天在 Windows 測 3.5，明天換 Mac 測 3.6，也不要偷偷換 Node、Vite 或 Browser，就是要固定！
Hardware
CPU / Memory
OS
Windows / macOS
Runtime
Node / Vite / TypeScript
Browser
Chrome + Version
環境一旦不同，測量結果就可能受到其他因素影響。
這可能是整個 Lab 最重要的一條，昨天我們已經把問題做成 Scenario，今天開始 Scenario 也不能為了讓新版 Vue 看起來更漂亮而修改。
例如：
reactive-chain
Vue 3.5
│
└── 同一份 Scenario
Vue 3.6
│
└── 同一份 Scenario
不能變成：
Vue 3.5
└── 1000 reactive dependencies
VS
Vue 3.6
└── 500 reactive dependencies
這樣測到的就不再是 Vue 版本差異，而是 Scenario 差異，所以我們會把 Scenario 視為一份「凍結的實驗條件」。
例如 huge-table，如果 Vue 3.5 測 const rows = 10000 Vue 3.6 就不能變成 const rows = 5000 ，操作流程也一樣。
Load
↓
Scroll
↓
Sort
↓
Pagination
兩個版本必須跑完全相同的流程，否則最後比較的其實不是 Vue 3.5 vs Vue 3.6，而是 Scenario A vs Scenario B
最後，我們把規則收斂成最簡單的一句話：
┌───────────────────────────────────────┐
│ Validation Lab │
│ │
│ Hardware SAME │
│ OS SAME │
│ Browser SAME │
│ Node / Vite SAME │
│ Scenario SAME │
│ Data SAME │
│ Operation SAME │
│ │
│ Vue Version ← ONLY CHANGE │
└───────────────────────────────────────┘
這樣當結果出現差異時，我們才有資格開始問 是不是 Vue 效能提升默默消化的？
有了固定規則之後，下一個問題就是 到底要拿什麼當比較基準？
答案就是 Baseline。
例如：我們先用 Vue 3.5 跑一次 Scenario -> Vue 3.5 -> Baseline 這個結果不是「標準答案」，它只是告訴我們在這個固定 Scenario、固定環境下，Vue 3.5 的成本是多少。
接著才換成 Vue 3.6 重新跑過剛剛 Vue3.5 跑過的路程，最後再把兩邊的 Evidence 放在一起。
Same Scenario
│
├──── Vue 3.5 → Baseline
│
└──── Vue 3.6 → Experiment
這時候我們才開始問結果，問差異，找問題根源！
Vue 3.5
│
│
├──────────────┐
│ │
↓ ↓
Baseline Compare
↑
│
Vue 3.6
│
↓
Experiment
走到這裡，昨天建立的六個 Scenario，終於有了真正的用途。
真實 Pain
│
↓
建立 Scenario
│
↓
Freeze Test Condition
│
↓
Vue 3.5 Baseline
│
↓
只換 Vue 版本
│
↓
Vue 3.6 Experiment
│
↓
Compare Evidence
│
↓
Engineering Decision
這條流程之後不只可以比較 Vue 3.5 和 3.6，未來換成 Vue 3.7、Vue 4，甚至其他重大 Runtime 變更，都可以重新走一次。
到目前為止，我們已經解決了 怎麼公平比較？，可是下一個問題馬上就出現了 到底要比較什麼？
我們知道比較前後版本，但是要看什麼呢？FPS 嗎？還是 Component Render Count？JavaScript Execution Time？Memory？Runtime Flame Chart？
如果每個 Scenario 單看一個指標說 Yes/ No，很容易再次得到錯誤結論，所以明天我們要做的事情就是把這些問題整理成一套 Evidence Matrix。
讓每一次 Vue 版本比較，都不只是「看」起來比較快，而是可以回答哪一種「成本」變了？
iThome鐵人賽
看影片追技術