初級工程師學技術，資深工程師學取捨。你覺得 senior 跟你的差距是寫 code 速度嗎？不是，是做判斷的準確度。
先講結論
沒有「完美方案」，只有「在你的限制條件下最合理的方案」。大部分工程決策是可逆的，不要花三週追求 100 分——做了 80 分的決定然後立即執行，贏過完美主義拖延。
核心張力
所有工程取捨都可以歸結為幾組永恆的張力：速度 vs 品質、簡單 vs 彈性、一致性 vs 可用性、自建 vs 外購。
這些不是二元選擇，是一個光譜。你的工作是找到你的情境下光譜上的最佳位置。
框架一：限制條件矩陣
做決策前先搞清楚限制：
- 時間：Deadline 多緊？→ 緊的話傾向簡單方案
- 人力：團隊多大？→ 人少傾向用現成工具
- 規模：使用者多少？→ 規模小不需要過度設計
- 生命週期：系統要活多久？→ 短期的話技術債可以接受
- 可逆性：這決定後面能改嗎？→ 可逆就大膽選快速方案
「可逆性」是最被低估的維度。 Jeff Bezos 的分類：Type 1（不可逆）要慎重多想幾天，Type 2（可逆）快速做錯了再改。大部分工程決策是 Type 2，但我們常當 Type 1 對待。
框架二：速度 vs 品質（是偽命題）
「速度 vs 品質」真正的問題是短期速度 vs 長期速度。
快速實作 → 技術債累積 → 改動變慢 → PM 問為什麼越來越慢。
判斷指南：地基要穩，上面的建築可以快。 資料模型、認證系統、核心 API 花時間做好。UI、文案、次要功能快速迭代。
涉及金錢或安全？品質優先。MVP 驗證假設？速度優先。會被多人長期維護的 code？品質優先。可以用 feature flag 漸進替換？速度優先。
框架三：自建 vs 外購
問你自己：這東西壞了，你願意凌晨三點起床修嗎？ 如果不願意，用外部服務。
常見錯誤判斷：
- 「自己寫比較好控制」——控制的代價是維護，你準備好了嗎？
- 「這套件太肥只需要一個功能」——你確定自己寫的不會越長越肥？
- 「付費工具太貴」——跟工程師的時間成本比呢？
核心判斷：這是你的核心競爭力嗎？不是的話就買。
框架四：決策記錄（ADR）
好的取捨不只要做出來，還要記下來。三個月後沒人記得為什麼這樣做。
# ADR-001: 使用 PostgreSQL 而非 MongoDB
## 決定
選 PostgreSQL。
## 理由
- 資料結構明確，不需要 schema-less 彈性
- 需要 ACID transaction（訂單不能出錯）
- 團隊有 PG 經驗
## 取捨
- 放棄 MongoDB 的 schema 彈性（可接受）
- Schema 變更需走流程（但這其實是好事）新人看了知道為什麼、三個月後的你知道為什麼、前提改變時知道該重新評估。
常見判斷偏誤
你在做決策時，小心這些：
- 沉沒成本：「已經花兩週寫了不能放棄」——問：重新開始你還會選這方案嗎？
- 過度工程：「萬一以後 10 萬使用者」——問：現在多少？半年內多少？
- 從眾偏誤：「大公司都用 K8s」——問：你的規模需要嗎？
- 完美主義：「再花一天做到 100 分」——問：90 到 100 值得那一天嗎？
實用決策流程
1. 可逆嗎？ → 可逆：花 30 分鐘想，然後做
2. 列 2-3 個選項（不超過 3 個）
3. 每個選項問：最好/最壞/最可能的情況？
4. 限制條件矩陣過濾
5. 做決定，寫 ADR，往前走
延伸閱讀
- 技術債管理 — 借債就是一種取捨
- 系統規劃方法論 — 規劃階段就是做取捨的時候
- Monorepo vs Multirepo — 經典取捨案例
你上次花超過一天在技術決策上是什麼時候？那個決定是 Type 1 還是 Type 2？如果是 Type 2——你可能花太多時間了。