作者：蒂莫西海伊（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：参见上篇《记录决策理由》。