架构验证的时间

架构设计的各种方法论是为把事情变得更简单易懂而准备的，它们帮我们梳理复杂应用的逻辑头绪，把我们不能一下子掌握的事情通过一种有条不紊的途径消化掉。可以说，把事情变得更简单是架构设计的远景和目标。但这种简单是有条件的，实用就是它的条件。所谓实用就是要满足各种各样外部环境并尽可能的提供更多的指标，这些指标包括可伸缩性、可维护性、学习曲线、稳定性等。所谓的尽可能就意味着需要有一个平衡点，我们需要通过各种努力来实现一个NP问题的解。

由于技术在大多数情况下都不是唯一的，同一问题解决方案可以非常多样。对于不同的架构，特别是稍微复杂一点的，相互很难能说服对方，项目真正进入实施阶段后这些不同所带来的影响就慢慢的浮出水面。之所以两个架构师可能会对同一问题得到两种截然不同的解，原因是多方面的：

• 对问题领域的理解不同；
• 个人经验不同，其中有感情的因素；
• 思考问题的方法不同；
• 出发点和侧重点不同。

这其中，个人经验占的比重相当大。个人经验在某些情况下会变成一种感情的因素，成了阻碍和排他的根源。实践是检验真理的唯一标准，来源于实践的经验理应得到感情的偏爱。不仅要用实践来检验正确的事情，也要用实践来验证错误的决策。排他法就是这个意思。

现在的很多应用模式，其实就是由实践检验过的解决方案。我们通常会在架构设计的时候自觉不自觉地引用成熟的架构模式，它往往能带来事半功倍的效果。但事情总不是那么顺利，失败的项目仍然比比皆是。原因就在于对模式的理解，或者说本身模式的描述就不全面。每一个应用都有自身的特殊性，放之四海而皆准的真理在这个世界上并不多见。所以，我们需要在架构设计中引入架构验证的环节。

危险来自不确定性，架构验证是一个非常重要的环节，它能在很大程度上预期项目的远景。架构设计过程通常把架构验证的时间放得比较靠后，很多时候我们是先有了一个通过经验（或感情）取得的一个模型之后再来找证据。这些证据确实说明了大多数问题，但不幸的是，20%的漏洞往往决定了80%的失败。这是种先入为主的思考问题的方式，它很难能给出最优解。更好的方法是在架构设计之初，综合当时能综合的因素得到一些不同的架构方案并对各个方案进行先期验证。这是一种排他法，非常的古老和简单。

验证的目的就是要避免来自不确定性的危险。如果某个结论是确定的了，或者是长期的实践检验过的了，通常没必要耗费时间去验证了。用确定性的东西越多，项目的预期也就越确定。有人喜欢求新求时尚，但新东西往往是付带着许多不确定的因素。比如面向对象是被长期检验过的了，而SOA就还是比较新的东西。

先期的架构验证要避免的一个问题是流于形式，或者说仍然带着感情的因素去做验证。并不是说把一些个条条框框搬出来对比就能得出结论的，更多的时候需要理性的思维，毕竟计算机仍然是一门科学。科学的东西最好是用数据说话。我很少看到哪个架构设计文档会把几个可选的架构放在一起用数据进行比较得出结论的情况，往往是纸上谈兵的方式比较常见。有经验的架构师手里应该掌握了很多数据，这些数字在很多时候比争论要来得直接得多。

结论：用证据筛选架构而不是为架构找证据，使用成熟的技术避免风险。不仅是架构设计，对很多事情最好都能养成先期验证的习惯。