[methodology] 取捨決策框架：工程師的判斷力怎麼練

cover

取捨決策框架：工程師的判斷力怎麼練

初級工程師學技術，資深工程師學取捨。

為什麼取捨能力這麼重要

工程師每天都在做取捨，但很多人沒意識到：

這個 function 要不要加 cache？
這個 bug 要徹底修還是先 workaround？
這個需求要自己寫還是用第三方套件？
測試要寫到多細？100% coverage 嗎？
Schema 要正規化到什麼程度？

每一個選擇都是取捨。 沒有「完美的方案」，只有「在你的限制條件下最合理的方案」。

資深工程師之所以資深，不是因為他們寫 code 寫得更快，而是因為他們做判斷做得更準——知道什麼時候該追求品質、什麼時候該追求速度。

取捨的基本模型

所有工程取捨都可以歸結為幾組核心張力：

graph TD
    A[速度] <-->|永恆的張力| B[品質]
    C[簡單] <-->|永恆的張力| D[彈性]
    E[一致性] <-->|永恆的張力| F[可用性]
    G[自建] <-->|永恆的張力| H[外購]

這些張力不是「選 A 或 B」的二元選擇，而是一個光譜。你的工作是找到在你的情境下，光譜上的最佳位置。

框架一：限制條件矩陣

做決策之前，先搞清楚你的限制條件：

維度	你的現況	影響什麼
時間	Deadline 多緊？	時間緊 → 傾向簡單方案
人力	團隊多大？能力如何？	人少 → 傾向用現成工具
規模	使用者多少？資料量多大？	規模小 → 不需要過度設計
生命週期	這個系統要活多久？	短期 → 技術債可以接受
可逆性	這個決定後面能改嗎？	可逆 → 大膽選擇快速方案
影響範圍	改動會影響多少人/系統？	影響大 → 需要更謹慎

「可逆性」是最被低估的維度。 如果一個決定很容易改，就不要花太多時間在上面。

Jeff Bezos 的分類法：

Type 1 決定（不可逆）：要慎重，多想幾天
Type 2 決定（可逆）：快速做，做錯了再改

大部分工程決策都是 Type 2，但我們常常把它們當 Type 1 來對待。

框架二：速度 vs 品質

這是最常見的取捨。但「速度 vs 品質」其實是個偽命題——真正的問題是「短期速度 vs 長期速度」。

短期視角:
快速實作 → 馬上交付 → Happy PM

長期視角:
快速實作 → 技術債累積 → 改動變慢 → PM 問為什麼越來越慢

判斷指南：

情況	傾向速度	傾向品質
MVP / 驗證假設	✓
核心業務邏輯		✓
使用者不到 100	✓
會被多人長期維護的 code		✓
可以用 feature flag 漸進替換	✓
涉及金錢或安全		✓
競爭對手已經有類似功能	✓
這是系統的地基（auth, data model）		✓

經驗法則：地基要穩，上面的建築可以快。 資料模型、認證系統、核心 API 要花時間做好。UI、文案、次要功能可以快速迭代。

框架三：自建 vs 外購（Build vs Buy）

考量	傾向自建	傾向外購
這是你的核心競爭力嗎？	是	不是
你有能力維護嗎？	有	沒有
外部方案符合你的需求嗎？	不符合	80% 以上符合
外部方案的鎖定風險？	鎖定嚴重	可替換
你的團隊規模？	大，有餘力	小，每個人都滿載

常見的錯誤判斷：

「自己寫比較好控制」— 控制的代價是維護，你準備好了嗎？
「這個套件太肥了我只需要其中一個功能」— 你確定自己寫的不會越長越肥？
「付費工具太貴」— 跟工程師的時間成本比呢？

一個實用的思考： 如果這個東西壞了，你願意在凌晨三點起床修它嗎？如果不願意，用外部服務。

框架四：一致性 vs 可用性（CAP 思維的延伸）

不只是分散式系統才有 CAP 問題。日常開發中：

場景	一致性優先	可用性優先
金融交易	✓ 絕不能算錯帳
社群媒體動態		✓ 晚幾秒更新沒關係
庫存系統	✓ 不能超賣
搜尋結果		✓ 快速回應比精確更重要
使用者設定	✓ 改了就要生效
推薦系統		✓ 不完美的推薦比沒有好

思維方式： 問自己「如果這個資料有幾秒的延遲/不一致，使用者會發現嗎？會造成損失嗎？」

框架五：決策記錄（ADR）

好的取捨不只是做出來，還要記錄下來。三個月後沒人記得為什麼這樣做。

Architecture Decision Record 模板：

# ADR-001: 使用 PostgreSQL 而非 MongoDB
 
## 狀態
已採用（2024-09-15）
 
## 背景
我們需要選擇主資料庫。資料結構是結構化的訂單和使用者資料。
 
## 考量的選項
1. PostgreSQL — 強 schema, ACID, 成熟生態
2. MongoDB — 彈性 schema, 開發初期快
3. MySQL — 類似 PostgreSQL 但生態較小
 
## 決定
選 PostgreSQL。
 
## 理由
- 資料結構明確，不需要 schema-less 的彈性
- 需要 ACID transaction（訂單不能出錯）
- 團隊有 PostgreSQL 經驗
- 未來可能需要全文搜尋（pg_trgm）
 
## 取捨
- 放棄 MongoDB 的 schema 彈性（可接受，因為資料結構穩定）
- 放棄 MySQL 的更廣泛託管選項（可接受，主流雲都支援 PG）
 
## 後果
- 需要寫 migration files
- Schema 變更需要走流程（但這其實是好事）

寫 ADR 的好處：

新人看了就知道為什麼
三個月後的自己看了就知道為什麼
如果前提改變了，你知道該重新評估

常見的判斷偏誤

偏誤	表現	矯正方式
沉沒成本	「已經花了兩週寫這個，不能放棄」	問：如果重新開始，你還會選這個方案嗎？
過度工程	「萬一以後需要支援 10 萬使用者」	問：現在有多少使用者？半年內會有多少？
從眾偏誤	「大公司都用 Kubernetes」	問：你的規模需要 K8s 嗎？
新手偏誤	「我最近學了 X，我要用 X 解決所有問題」	問：這是 X 的最佳使用場景嗎？
完美主義	「再花一天就能做到 100 分」	問：從 90 分到 100 分值得那一天嗎？

一個實用的決策流程

當你面對一個工程決策時：

1. 這個決定可逆嗎？
   ├─ 可逆 → 花 30 分鐘想，然後做
   └─ 不可逆 → 繼續 ↓

2. 列出 2-3 個選項（不要超過 3 個）

3. 對每個選項問：
   - 最好的情況是什麼？
   - 最壞的情況是什麼？
   - 最可能的情況是什麼？

4. 用限制條件矩陣過濾

5. 做決定，寫 ADR，往前走

做了 80 分的決定然後立即執行，勝過花三週追求 100 分的完美方案。

反思問題

你上次花超過一天在一個技術決策上是什麼時候？ 那個決定是 Type 1 還是 Type 2？
你的團隊有 ADR 的習慣嗎？ 如果沒有，你知道半年前為什麼選了現在的框架嗎？
你有沒有過「自己寫了一個輪子，後來發現不如用現成的」的經驗？
你在做取捨時，最常忽略哪個維度？ 時間？可維護性？還是可逆性？

Terry Yao's Blog

分類

目錄