Debugging：先找 Evidence，再改 Code

Learning outcomes

• 能建立可重現的 bug description。
• 能把問題分成 syntax/build/runtime/network/data/logic/UI 等層。
• 能從第一個失敗 evidence 往前追 root cause。
• 能避免一次同時改很多東西。

1. 先重現

Expected:
click Save → course appears

Actual:
click Save → nothing visible

Environment:
Chrome, local dev, current commit X

無法穩定重現，就很難知道某次「修好」是不是只是碰巧。

2. 切層

Source syntax
  ↓
Build
  ↓
Runtime
  ↓
Event
  ↓
Network
  ↓
Server
  ↓
Database
  ↓
Render

你要找的是「最後成功的一層」和「第一個失敗的一層」。

3. 先讀 Error Message / Status / Stack

TypeError:
Cannot read properties of null

HTTP 404
Not Found

HTTP 500
Internal Server Error

三者指向完全不同 failure boundary，不應用同一種修法。

4. Hypothesis 要能被否證

Hypothesis:
button handler 沒有被呼叫

Experiment:
handler 第一行 log

Result:
log 出現
→ hypothesis rejected

這比「再重寫一次 handler」更有效率。

5. 最小改動

一次只改能驗證 hypothesis 的最小範圍。否則同時改 route、CSS、database 後成功，你也不知道真正原因。

Project checkpoint：Request Journey Map v4

Symptom: /courses blank

Evidence checklist:
1. HTML loaded?
2. JS loaded?
3. click handler ran?
4. request sent?
5. response status/body?
6. state updated?
7. DOM rendered?

6. 修好後要 Regression Evidence

before:
repro FAIL

after fix:
same repro PASS

plus:
neighboring cases still PASS

「現在看起來可以」不是完整驗證。