作者：蒂莫西海伊（Timothy High）
韋森“延期判決”法則（譯註1）（wethern's law of suspended judgment）以詼諧口吻如是說：“臆斷是事情搞砸的根源（Assumption is the mother of all screw-ups）。”另一種更爲流行的說法是“不要假設（assume）——它會讓你我出醜（make an 'ass' of 'U' and 'me'）（譯註2）。”但是，如果面對的是可以導致數千甚至數百萬美元損失的假設，你的心境就不會那麼輕鬆了。
軟件架構的最佳實踐表明，應該記錄下每個決策背後的理由（譯註3），當這一決策包含權衡（性能vs可維護性，成本vs上市時間等）時尤須如此。在更爲正式的方法中，記錄下每個決策的上下文是很常見的做法，這些上下文包含了促成最終決策的各項“因素”。這些因素，可能是功能性或非功能性需求，但也可能只是決策者認爲重要的“事實”（或道聽途說…），如技術約束、現有技能、政治環境因素等。
這種做法頗有價值，因爲列出這些因素有助於標明（highlight）架構師所持的假設，這些假設會影響到軟件設計中的重要決策。很多時候，這些假設往往是基於“歷史原因”、主觀判斷、開發人員的視野、因循守舊（FUDs），甚至“走廊裏聽來的一些小道信息”：
- “開源軟件不可靠。”
- “位圖索引（Bitmapindex）帶來的麻煩比好處多。”
- “客戶絕不會忍受一張網頁需要花5秒鐘才加載完成。”
- “只要不是主要廣商銷售的產品，首席信息官（CIO）都會拒批。”
確保這些假設清楚明確，對後繼者和未來重新評估來說，非常重要。但是更重要的是，一定要拿出相關的經驗證據（或者獲得參與者的確認），仔細驗證這個假設之後，纔可以做出最終決策。如果客戶爲了關鍵報表願意接受5秒的等待時間，而你卻提供的卻是相反的信息，那該如何是好？如果確認某個開源項目確實是不可靠的？對於“在數據中使用位圖索引”，是否通過應用程序的事務（transactions）和查詢（query）對之進行測試？
特別提醒，不在忽略“相關（relevant）”這個詞。老版本軟件中正確的一些東西，今天可能己經不再成立了。位圖索引的性能，在Oracle某個版本中和在另一個版本中，可能並不相同。某個舊版本的類庫中可能存在的安全漏洞，現在沒準己經被修復了。可靠的老牌軟件廠商在賬務上可能己是苟延殘喘。技術格局每天都在變化，人也是一樣。誰知道呢？也許你的CIO私底下己經變成Linux的狂熱擁躉了。
事實（fact）和假設（assumption）是構建軟件的兩大支柱。務必確保軟件的基石堅實可靠。
譯註1：韋森“延期判決”法則是軟件開發社區中流行的諸多詼諧法則之一。更多可見http://www.scs.uiuc.edu/suslick/laws.html。《持續集成》一書也曾引過此法則。
譯註2：注意assume這個單詞的拼寫，由“ass” + “u”（you） + “me”組成。
譯註3：參見上篇《記錄決策理由》。