避免象牙塔式的架构设计

    对软件来说，架构设计是一项至关重要的工作。这样的工作交给某个人是非常危险的。即便这个人再怎么聪明，他也可能会遗漏部分的细节。组织有效的团队的力量是大大超过个人的力量的，因此团队的成果较之个人的成果，在稳定性和思考的周密程度上，都要更胜一筹。

    Scott W. Ambler在其著作中给出了象牙塔式架构（ivory tower architecture）的概念：

    An ivory tower architecture is one that is often developed by an architect or architectural team in relative isolation to the day-to-day development activities of your project team(s).

    中国现在的软件开发行业中也逐渐出现了象牙塔式的架构设计师。这些架构师并不参与实际的程序编写，他的工作就是为项目制作出精美的架构模型，这种架构模型在理论上是相当完美的。

    优秀的架构师能够充分的利用现有框架，减少软件的投入，增强软件的稳定性。这些都没有错，但是问题在于“过犹不及”。象牙塔式架构师往往会出现文章开始指出的那些问题。架构设计其实并不是非常复杂的工作，但它要求开发人员具备相关的技能、经验以及对问题域有一定的了解。开发人员往往都具有相关的技术技能（编程、数据库设计、建模），而对问题域的理解可以从用户和行业专家那里获得帮助。因此，在理论上，我们要实现架构设计的团队化是完全可能的。

    在上面的象牙塔式架构定义中，我们看到架构师和日常的开发工作是隔绝的。这样的设计出的架构有很大的局限性。在现实中，我们还会发现另外一种角色，他来自于开发团队外部，为开发人员提供相关的技术或业务的培训。这种角色称为教练，在软件开发中是非常重要的角色，不能够和象牙塔式架构设计师之间画等号。

    选择你的设计团队

    软件的架构在软件的生命周期的全过程中都很重要，也就是说，软件开发团队中的所有人员都需要和架构打交道。因此，最好的团队组织方式是所有开发人员都参与架构的设计，我们称这种方式为全员参与。全员参与的方式保证了所有开发人员都能够对架构设计提出自己的见解，综合多方面的意见，在全体开发人员中达成一致。这种方式尤其适合于一些小的团队。

    还是会有很多的团队由于种种的原因不适合采用全员参与的方式。那么，组织优秀的开发人员组成设计组也是比较好的方式。一般，我们选择那些在项目中比较重要的，有较多开发经验，或是理论扎实的那些人来组成设计组。当然，如果你考虑到为组织培养后续力量，你也可以让一些新手加入设计组，或是你觉得自己的开发力量不足，邀请外部的咨询力量介入，这完全取决于具体的情况。

    设计组不同于我们之前提到的象牙塔式架构设计师。设计组设计出来的架构只能称为原始架构，它是需要不断的反馈和改进的。因此，在架构实现中，设计组的成员将会分布到开发团队的各个领域，把架构的思想带给所有开发人员，编写代码来检验架构，并获得具体的反馈，然后所有的成员再集中到设计组中讨论架构的演进。

    例2：敏捷方法非常注重的就是团队的沟通。沟通是一个很有意思的话题，讲起来会花费大量的时间，我们这里只是针对架构设计中可能存在的沟通问题做一个简单的讨论。我们这里假设一个讨论情境，这个情境来源于真实的生活：

    项目主管徐辉、设计师李浩、设计师罗亦明正在讨论一个新的软件架构。

    "李浩你认为这个软件数据库连接部分应该如何考虑？"徐辉问。

    李浩想了想，"我觉得方案A不错…" "方案A肯定有问题！这个软件和上一次的又不同。"罗亦明打断了李浩的发言。

    "你懂什么！你到公司才多久，方案A是经过很长时间的证明的！"发言被打断，李浩有点恼火，罗亦明进入公司没有多久，但在一些事情上老是和他唱反调。

    "我进公司多久和方案A的错误有什么关系！"

    在这样一种氛围中，会议的结果可想而知。