重视不确定性

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

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

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

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

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

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

译注1：推迟决定（defer commitment）是精益软件开发的原则之一。推迟决定不是故意拖延，而是强调作出的决定应该基于足够的事实，不能仅凭假定和猜测。

译注2：重要性（significance），指设计决策对系统影响程度。重要性用变更设计决策须要付出的代价来衡量，如果变更某个决策须要付出的代价高，那么其重要性就高，反之则低。

译注3：“期权思想”是指在期权交易中，权利的受让人可以在将来某个约定的时音，根据当时决定是否行使权利，即推迟作决定时间。