软件架构师应该知道的97件事之概括16 -30

16、不要在一棵树上吊死

负责构建系统的人似乎无法接受这样的事实：没有哪种数据类型、消息格式、消息传送机制，甚至主流的架构组件、策略、观点用来能够用来解决所有的业务问题，毕竟当大家都希望摆脱业务需求不断滋生的意外和烦恼。

才用多钟表现方式、多钟传输方式不是为了消遣。应当认识到，通过分解系统的非功能参数，可以为客户提供多样化的解决方案。

17、业务目标至上

在商业化的背景下开发企业应用，架构师必须成为业务部门和技术部门沟通的桥梁，周旋调解，兼顾双方利益，同时业务目标来驱动项目 开发。业务目标和实际的开发条件应该成为架构师主持制定决策的参照系统。

在启动一个软件项目之前，应当制定计划，明确投资回报的预期。架构师必须把握这个预期，并预估该项目的商业价值，避免做出错误的技术决策，造成经费超支。

用业务目标驱动项目开发，才能保证软件开发团队的长远利益。

18、先确保解决方案简单可用，再考虑通用性和复用性

许多用来实现基础设施的代码，包括组建、框架、类库、基础服务，普遍存在一个问题，它们设计一向强调通用性而不考虑具体应用。

如果存在多个可实施方案难以取舍，“先简单后通用”原则可以成为最终的评判标准。

虽然很多架构师重视通用性，但这样做是有前提条件的。并非所有人都需要通用性，愿意为它掏钱。

19、架构师应该亲力亲为

称职的架构师应该通过示范领导团队，架构师通常都取得过不错的业绩，有份出彩的简历，容易获得业务人员和技术人员的青睐。但除非他能展示自己的实践能力，否则很难赢得团队的尊重，团队成员将无法从他身上学到东西，大家甚至难以在他的领导下做好本职工作。

20、持续集成

架构师（无论是应用架构师还是企业架构师）都应该在项目中鼓励推广持续集成的方法和工具。

现在持续集成已经取代了“尽早构建，经常构建”（build early and often）的提法，它确保当前的开发不会出现意外，是一种降低风险的技巧。

构建应用程序是持续集成最主要的内容，它通常是自动执行的，可以设置在夜里执行，或者当源代码改变时自动触发。当然你也可以选择手动构建。

21、避免进度调整失误

导致项目失败的原因很多，最常见的是中途临时调整进度。

改变计划回答带来以下问题：

仓促的进度会导致拙略的设计、蹩脚的文档，可能引发质量问题，导致用户拒绝签收

仓促完成代码导致bug增多，测试不充分增加测试中可能出现的问题

以上问题均能引发产品质量问题，而解决产品质量的问题代价更高。最后的结果是成本不降反升，通常项目就是这样失败的。

22、取舍的艺术

架构师应该明白鱼和熊掌不可兼得的道理。如果2个性能本身就是冲突的，满足一项就会导致另一项失败或者整体失败。

23、打造数据库堡垒

创建牢固的数据模型要从第一天开始

牢固的数据模型既可以保障当前的数据的安全，又为今后提供可扩展性。要保障数据安全就必须隔离来自应用层的bug（在不断变化的应用层中这些bug无处不在，不会因为你的勤奋而消失），必须严格遵守引用完整性规则，尽量使用域约束规则，还要选择恰当的键，即保证数据的完整性，又遵守约束规则。要实现可扩展性，就必须正确地将数据标准化。以便今后在数据模型上添加架构层：千万不要偷懒走捷径。

为了妥善保护数据库必须拒绝无效数据，阻止无意义的关系。在定义键、外键、域约束时，应该采取简洁的容易被理解和验证的名称，使他们含义不言自明。数据模型中的域规则也要做到物理化和持久化，避免他们在应用逻辑发生改变时被删除。

为了充分发挥关系型数据库的作用——让它真正的成为应用的一部分，而不仅仅是存放数据的库房——必须从开始构建数据库时，就深刻理解业务需求。随着产品的演变，数据层也会发生变化。

24、重视不确定性

当你面临2中选择的时候应该仔细考虑设计中的不确定性。

迫于压力，人们常常为了决策而决策。这时可以借鉴期权思想（指在期货交易中，权利的受让可以在将来的某个约定的时间，根据当时的情况决定是否行使权利，即推迟做决定时间），当你在不同的系统开发路线之间举棋不定时，不要急于做出决策。推迟决策，直到掌握更详实的信息，以便做出更可靠的决策。但也别太迟，要赶在这些信息失效前利用他们。

25、不要轻易放过不起眼的问题

问题出现时，虽然个别团队成员会发现一些端倪，但往往由于大多数人认识不到其严重性，这些问题不是被忽略就是被搁置，知道变得难以解决。

注意造成的原因和哪些方法克服这些消极因素。

26、让大家学会复用

有这样一种观点，认为设计优良的框架、细致考虑并精巧实现的架构自然会被人们重复利用。

但也是在满足下列条件下擦可能被复用：

大家都知道它的存在

大家知道如何使用它们

大家认识到利用已有资源好过自己动手

27、架构里面没有大写“I"

英文单词架构（architecture）里面有字母”i"但不是大写的“I”。它代表的不是那个喜欢唤起别人关注，喜欢凌驾于众人之上的“I"(自我）。

自我可能是我们这最大的敌人。

如何避免犯错误？

需求不会撒谎。

重视团队合作。

检查你的工作。

自我反省。

28、使用”一千英尺高“的视图

用来了解正在开发的软件质量如何

在架构图中，系统是由若干个小方框组成的，方框之间的连线代表着各种含义：

依赖关系、数据流、共享资源等。

这种图好比从飞机上俯瞰地面上的风景，我们称之为“三万英尺高”的视图。另一种典型的视图是源代码，好比占在地面上看大地。两种视图都无法冲分钟展现软件的质量：前者太抽象，而后者细节太多，以至于我们看不清整个架构。很显然我们需要一个介于2着之间的视图——“一千英尺高”的视图。

"一千英尺高“的视图提供的信息来自恰当的层次，囊括大量数据和多钟度量标准，例如方法数，类扇出数和圈复杂度。具体的视图与特定的质量属性密切相关。

一旦我们绘制出合适的视图，判断软件质量就更客观了。

29、先尝试后决策

创建一个应用需要作出很多决策。有些决策设计挑选框架和函数，而另一些则需要选定特定的设计模式。

架构师应该持续关注那些马上要制定的决策，架构师可以在决策之前，要求几个开发人员商量解决方案，比较不同解决方案的优点和弊端。

对同一个问题尝试2种或者2种以上的解决方案，可能是代价最低的选择。事后发现方案不合适或者是没人发现方案不合适都是糟糕的情况。

30、掌握业务领域知识

高水平的软件架构师不仅要懂技术，还要掌握问题空间对应的业务领域的知识。缺乏业务领域知识的架构师不能顺利地解决问题，无法把握业务目标和业务需求，也就难以设计有效的架构来满足需求。