降低开发的成本

    不论是模式，可重用组件，或是框架技术，目的都是为了降低开发的成本。但是他们的方式是先进行大量的投入，然后再节省后续的开发成本。因此，架构设计方面的很多思路都是围绕着这种想法展开的，这可能也是导致开发人员普遍认为架构设计高不可攀的原因。

    XP的方式恰恰相反，在处理第一个问题的时候，不必要也不可能就设计出具有弹性、近乎完美的架构来。这项工作应该是随着开发的演进，慢慢成熟起来的。我不敢说这种方式肯定正确，但是如果我们把生物的结构视同为架构，这种方式不是很类似于自然界中生物的进化方式吗？

    在一开始就制作出完美的架构的设想并没有错，关键是很难做到这一点。总是会有很多的问题是你在做设计时没有考虑到的。这样，当一开始花费大量精力设计出的"完美无缺"的架构必然会遇到意想不到的问题，这时候，复杂的架构反而会影响到设计的改进，导致开发成本的上升。这就好比如果方向错了，交通工具再快，反而导致错误的快速扩大。Martin Fowler在他的论文中说，"Working on the wrong solution early is even more wasteful than working on the right solution early"（提前做一件错事要比提前做一件对的事更浪费时间），相信也是这个道理。

    更有意思的是，通常我们更有可能做错。在我们进行架构设计的时候，我们不可能完全取得详细的需求。事实上，就算你已经取得了完整的需求，也有可能发生变化。这种情况下做出的架构设计是不可能不出错的。这样，浪费大量的时间在初始阶段设计不可能达到的"完美架构"，倒不如把时间花在后续的改进上。

    提升沟通的效率

    我们在团队设计中已经谈过了团队设计的目标之一就是为了降低沟通的成本，以期让所有人都能够理解架构。但是如果架构如果过于复杂，将会重新导致沟通成本的上升，而且，这个成本并不会随着项目进行而降低，反而会因为上面我们提到的遇到新的问题导致沟通成本的持续上升。

    简单的架构设计可以加快开发团队理解架构的速度。我们可以通过两种方式来理解简单的含义。首先，简单意味着问题的解不会非常的复杂，架构是解决需求的关键，无论需求再怎么复杂多变，总是可以找出简单稳定的部分，我们可以把这个简单稳定的部分做为基础，再根据需要进行改进扩展，以解决复杂的问题。在示例中，我们提到了measurement pattern，它就是按照这种想法来进行设计的。

    其次，简单性还体现在表示的简单上。一份5页的文档就能够表达清楚的架构设计为什么要花费50页呢？同样的道理，能够用一副简单的图形就能够表示的架构设计也没有必要使用文档。毕竟，面对面的沟通才是最有效率的沟通，文档不论如何的复杂，都不能被完全理解，而且，复杂的文档，维护起来也需要花费大量的时间。只有在两种情况下，我们提倡使用复杂的文档：一是开发团队没有办法做到面对面沟通；二是开发成果要作为团队的知识积累起来，为下一次开发所用。

    考虑未来

    我们之所以考虑未来，主要的原因就是需求的不稳定。因此，我们如果考虑未来可能发生的需求变化，就会不知觉的在架构设计中增加复杂的成分。这违背的简单的精神。但是，如果你不考虑可能出现的情况，那些和目前设计格格不入的改变，将会导致大量的返工。

    还记得YAGNI吗？原则上，我们仍然坚持不要在现有的系统中为将来可能的情况进行设计。但是，我们必须思考，必须要为将来可能出现的情况做一些准备。其实，软件中了不起的接口的思想，不就是源于此吗？因此，思考未来，但等到需要时再实现。

    变更案例有助于我们思考未来，变更案例就是你在将来可能要（或可能不要）满足的，但现在不需要满足的需求。当我们在做架构设计的时候，变更案例也将会成为设计的考虑因素之一，但它不可能成为进行决策的唯一考虑因素。很多的时候，我们沉迷于设计通用系统给我们带来的挑战之中，其实，我们所做的工作对用户而言是毫无意义的。

    架构的稳定

    架构简单化和架构的稳定性有什么关系吗？我们说，架构越简单，其稳定性就越好。理由很简单，1个拥有4个方法和3个属性的类，和1个拥有20个方法和30属性的类相比，哪一个更稳定？当然是前者。而架构最终都是要映射到代码级别上的，因此架构的简单将会带来架构的稳定。尽可能的让你的类小一些，尽可能的让你的方法短一些，尽可能的让类之间的关系少一些。这并不是我的忠告，很多的设计类的文章都是这么说的。在这个话题上，我们可以进一步的阅读同类的文章（关于 refactoring 的思考）。