組態是一種人機介面——每一個選項都是系統在向使用者「問一個問題」。它該被刻意設計，兼具 API 與 UI 設計的特質，而不是系統實作留下的副產品。設計得好，變更就能快速、有信心且可測試。
🧠 Intuition
IMPORTANT
最理想的組態是不需要組態：系統能依部署、工作負載或既有設定自動辨識正確值。這在實務上很難完全達成，但它指出方向——從大量可調參數走向簡潔。
- 組態的品質直接牽動可靠性，但它和程式碼有三個關鍵差異：影響範圍大（一條錯規則就能把你鎖在系統外）、缺乏測試（常在未經測試甚至不可測試的環境）、壓力下操作（事故期間得在巨大壓力下改）。
- 把設計拆成兩層來想：組態哲學（如何結構化、抽象到什麼層次，與語言無關）與組態機制（語言設計、部署策略、與其他系統互動）。分開推理才清楚。
- 問題要接近使用者目標：讓人用自己的術語說「熱綠茶」，而不是逼他指定水量、水溫、浸泡時間、杯型。描述高層次目標時，系統還能隨時間改進實現方式。
- 減少旋鈕會降低對系統的掌控度，但也縮小錯誤表面積、減輕認知負荷——有限的選項反而帶來更好的採用率，因為軟體幾乎「開箱即用」。
⚖️ Tradeoffs
基礎架構導向（旋鈕多） vs 使用者導向（旋鈕少）
- 基礎架構導向：提供越多組態旋鈕越好，讓使用者能精確調校。代價是上手成本高、認知負荷重——就像 NASA 太空船控制中心，掌控力強但要求操作員接受大量訓練，這在現代多數產業已不可行。
- 使用者導向（本章偏好）：組態是使用者回到實際業務目標前必須回答的問題，旋鈕越少越好。
- 折衷是選擇性覆寫預設：先設「綠茶」，再補「浸泡五分鐘」——預設保持高層次、貼近目標，但允許進階者微調低層次細節（類比高階語言容許插入機器指令）。
必要問題 vs 選擇性問題＋動態預設
- 必要問題（Mandatory）：不回答就無法提供任何功能（如計費帳號）。為維持易採用，應最小化必要問題數量。
- 選擇性問題（Optional）：不影響核心功能，回答後能改善品質（如 worker 數量）。把必要問題轉為選擇性、附上適用多數人的預設值，是最簡單的做法。
- 動態預設（Dynamic Defaults）：預設不必是硬編碼靜態值——可依容器核心數自動決定計算執行緒數，或依可用記憶體調整 Java 堆積限制。要謹慎：多數人會沿用預設，這既是機會也是責任。
🔑 Takeaways
- 組態＝在向使用者提問；問題要貼近使用者目標，並把「理想的組態是不需要組態」當成減少旋鈕的北極星。
- 分離哲學與機制；機制上讓組態「兼具程式碼與資料但彼此分離」——使用者透過高階介面（DSL、Web UI）互動，系統基礎架構操作純靜態資料，中間過程像編譯。用語意驗證、linter、自動格式化等工具把地雷擋在前面。
- 安全的變更要能漸進式部署、可回滾、失控時自動停止；而要能安全前滾／回滾，組態必須是封閉的（hermetic），不可依賴封閉環境外的可變外部資源。
No notes yet — jot your takeaways or Q&A here.