組態參數是把複雜性「往上推」的典型範例。

不在內部決定行為，而是暴露幾個參數讓使用者去設定：

• cache 的大小
• 重試次數
• ……等

當代系統很愛這套，有些系統甚至有上百個組態參數。

支持者的論點#

• 讓使用者能依需求與工作負載調整系統
• 在某些情況下，底層基礎設施程式碼確實不知道最佳策略；使用者更熟悉自己的領域
• 例如：使用者知道某些請求對時間敏感，所以為它們指定較高優先權
• 在這類情況中，組態參數能在更廣的領域帶來更好的效能

但組態參數也是「逃避責任」的好藉口#

• 把難題甩給別人
• 很多時候，使用者或管理員根本無法決定正確的值
• 有時候多花點力氣在實作裡，就能自動算出合適的值

範例：網路協定的重試間隔#

某網路協定要處理封包遺失：

• 如果送出請求後一段時間內沒收到回應，就重送

設計選擇：

後者明顯更好——既不需要使用者懂 RTT，也讓系統具有自適應性。

設計建議#

應盡量避免組態參數。

暴露組態參數前先問自己：

「使用者（或上層模組）真的能比我這裡決定出更好的值嗎？」

若必須建立組態參數：

• 看看能不能自動算出合理的預設值
• 讓使用者只在例外情況才需要提供值

理想上每個模組都應完整解決一個問題。

組態參數代表的是「不完整的解」——它把複雜性推到系統其他地方。