23 重视不确定性

面临两种选项时，多数人认为最重要的是丛中选择，然而设计（无论是软件设计还是其他设计）并不是这样的。当你面对两种可能性时，应该仔细考虑设计中存在的不确定性。不确定性可以促使你推迟决定，收集更多的信息：促使你用分隔和抽象的方法来降低设计决策的重要性。如果抱着头脑中最先闪现的想法不放，被它束缚，偶然性决策就会占上风，软件的灵活性会降低。

格雷迪.而厅对架构的定义是众多定义中最简单也最具有建设性的：“架构属于设计范畴，但并非所有的设计都属于架构之列。架构代表了那些形成系统的重要设计决策。其重要性由变更决策的代价来衡量。”也就是说，优良的架构 能够从整体上降低设计决策的重要性，糟糕架构则会突出重要性。

如果出现两个合理的选择，架构师应该停下来，设法找同出介于两者之间的、具有更低重要性的决策，而不是简单地在两者中作出选择。了解两者之外还存在其他选择（这个选择并非显而易见），比决策结果本身更有价值。

架构师往往冥想苦思反复尝试，才能清楚地将问题一分为二。当你积极地与同事在白板前争论不同的可能性时，当你对着代码反复琢磨而无法决定采用哪种实现方式时，当新的需求或对需求的新解释质疑现有实现方式时，说明你碰到不容易确定的情况了，这时要设法利用分离或封装将决策和最终依赖于决策的代码隔离开。做不到这一点，代码就会杂乱无章，仿佛一个紧张的应聘者，试图用模棱两可、含糊其辞的方式回答没有把握的问题。还有些盲目自信的人会作出武断的选择，但是开快车又不愿回头看是会拐错弯的。

迫于压力，人们常常为了决策而决策。这时可以借鉴期权思想。当你在不同的系统开发路线之间举棋不定时，不要急于作出依赖。推迟决策，直到掌握更详实的信息，以便作出更可靠的决策。但也别太迟，要赶在这些信息失效利用它们。

架构和过程相互交织，所以架构师应该在开发周期中促成那些注重实证的架构方法，并设法引出反馈，建设性地利用不确定性，将系统和进度分割开来。