重點摘要#

• 假設是所有失誤之母——處理可能耗費千萬的架構決策時，這不是開玩笑的事
• 最佳實踐要求記錄每個決策背後的理由，包括影響決策的**「因素」（facts and assumptions）**
• 未經驗證的假設必須在決策定案前被挑戰和確認
• 技術環境和人事都在變化，過去的假設不一定仍然成立

詳細內容#

Wethern 的「暫緩判斷法則」半開玩笑地指出：「假設是所有搞砸的根源。」更常見的說法是「不要假設」。但當你在處理可能花費數千甚至數百萬元的決策時，這絕對不是開玩笑的事。

記錄並審視假設#

最佳實踐建議記錄每個決策背後的理由，特別是涉及權衡取捨的決策。同時也應記錄影響最終判斷的「因素」——這些因素可能是功能性或非功能性需求，也可能是決策者認為重要的「事實」（或事實碎片）。

常見的危險假設#

這些假設常基於「歷史原因」、開發者傳說、恐懼不確定、或「我在走廊上聽到的」：

• 「開源不可靠」
• 「Bitmap 索引不值得使用」
• 「客戶絕對不能接受載入超過 5 秒的頁面」
• 「CIO 會拒絕非主要供應商的產品」

不要忽視「相關性」這個詞。在舊版軟體中成立的事情，在今天不一定成立。技術環境每天都在變化，人也是如此。也許你的 CIO 已經悄悄變成了 Linux 的粉絲。

驗證假設#

任何不基於相關實證的假設（或者對於政治因素，來自相關人員的確認），都必須在決策定案前被驗證。例如：

• 如果你提供一個計數器，客戶真的願意等 5 秒嗎？
• 你是否用自己應用程式的交易和查詢測試過 bitmap 索引？
• 到底哪個開源專案不可靠？具體的問題是什麼？

事實和假設是你軟體建構的基石。無論它們是什麼，確保這些基礎是穩固的。

— By Timothy High