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

76、命名要恰如其分

如果都不知道一个东西应该叫什么，那你肯定不知道它究竟是什么。如果你不知道它究竟是什么，那么你肯定不能坐下来为它编写代码。

77、稳定的问题才能产生高质量的解决方案

最好的架构师不是要去解决难题，而是围绕难题开展工作。架构师要能够将四处弥漫的软件问题圈起来，并画出其中的各种边界，确保对问题由稳定的、完整的认识。

这些问题应该具有以下特性：

*内聚性：问题块在概念上市统一的，其中所有的任务、数据和特征都是相关的。

*能够很好地和其他块分隔开：这些块在概念上进行了规范化处理；他们很少重叠或者根本不重叠。

78、天道酬勤

架构师常常被描述为一种注重创造力与问题解决能力的职业。除了创造力外架构师还应当具备另一项同样重要的特质——勤奋，勤奋指很多方面，但归根结底是指具备坚强的毅力，并且对系统的每项任务和每个架构的目标都能投入足够精力。

勤奋经常和平凡携手同行。

勤奋还意味着要求架构师必须真正做好那些看似简单的任务，坚守承诺。

79、对决策负责

由于软件架构师比组织中的其他人更有影响力，所以他们必须对自己做出的决策负责。

研究表明有超过三分之二的软件项目要么彻底失败了，要么未能成功交付（项目延期、预算超支、客户不满意）。究其根本原因，有许多事由于架构师做出了不当的决策，或者无法最终执行正确的架构决策。

如何做出有效的架构决策：

首先,对决策的过程有充分认识

第二，定期对架构决策进行复审

第三，要贯彻架构决策

最后，可以将一些决策委托给响应问题域的专家，不必出自其自身。

80、弃聪明，求质朴

智力超群、足智多谋对任何人来说都是值得称道的品质。对架构师来说，这些素质尤其被看重。

然而，聪明也包含某些额外的隐含意义。它也暗指能快速想出脱身之计的能力，但这种本领最终要依靠一些小伎俩，骗局或掉包计。

聪明的设计僵硬难改，其细节会对全局产生太多牵扯，往往会一触即毁。

81、精心选择有效的技术，绝不轻易放弃

作为软件设计开发的老手，每个架构师通常都有一些让自己屡屡取胜的武器用来武装自己。这些技术由于种种原因深受架构师青睐，排在其首选解决方案的前几位。这并不是说某种技术一旦入围就可以永久罔替。

选择新技术虽然有风险，但其价值能为你带来质的飞跃。

考虑技术未来的前景。

软件架构师工作很大一部分，是要选择用以攻克难题的合适技术。

82、客户的客户才是你的客户

在软件会议需求会议上，要这样想象：你的客户并不是你的客户。实际上真的不难做到，因为，事实便是如此。如果你的客户的客户赢了，那么你也赢了。

如果你在编写一个电子商务应用程序，那么应该考虑的应当是那些会在那个网站上购物的人的需求。如果你的客户有意无意的忽视他们的客户所看重的重要事项——那么请放弃这个项目。

需求收集会议不是项目实现讨论会议。

83、事物发展总会出人意料

事物的发展总会出人意料。在设计时，人们很容易陷入误区，投入太多的时间在设计上。

设计中的这些微小变化累积起来，很快就需要对设计进行一次较大的变更。

设计是一个不断发现的过程。

84、选择彼此间可协调工作的框架

软件框架是系统的基础，在选择时，不仅要考虑每个框架自身的质量和特性，也要关注共同构成系统的各个框架之间是否能和谐相处。

如果框架间有重叠，则要确保了解候选框架在逻辑域或关注层面上的重叠程度。

为了尽量减少框架间互有重叠的概率，要根据系统需求的应用场合，选择精专强大的框架。

系统应该由多个相互独立的框架构成，其中每个框架都精专于各自的领域，但同时又非常简洁、包容、灵活。

85、着重强调项目的商业价值

对于非软件业从业人员，软件架构显得虚无缥缈，架构项目在争取资金时会遭遇到困难。

大众心理学表明，大部分人会相信亲眼所见的东西。而拥有预算决定权的人，几乎都是受商业价值驱使的。

下列五部，会成功将架构提案打造成经典的商业项目：

1、形成价值描述（提高 生产力，改进效率的能力）

2、建立量化度量标准

3、回过头来关联传统商业的衡量方式

4、知道该在哪里停止

5、寻找恰当的时机

86、不仅仅只控制代码，也要控制数据

源代码的控制和持续集成，是管理应用程序构建过程和部署过程的优秀工具。数据方案和数据内容常常会根据源代码的变化而变化，他们也是这一过程的重要组成部分，因此也要对之进行类似的控制。

数据库的变化不应该影响构建活动的连续性。要把数据库也作为一个构建单元包含在内，做到一次性构建整个应用程序。数据迁移不应该作为一种补救措施。

87、偿还技术债务

对任何已投入实用的项目（也就是说，有客户在实用产品），无论是要修复缺陷，还是要添加新功能，总有必须修改产品的时候。在那点上，会面临2个可能选择：花合适时间“一次做对”，或者取巧走“捷径”，争取尽快推出修改过的产品。

作为架构师必须决定怎么做才有意义。

88、不要急于求解

架构师多半是开发人员出身。开发人员的主要职责是解决编程问题。相比架构问题编程问题的范围更狭窄。很多编程问题是很小但比较棘手的算法问题。

架构师和开发人员因此学会了迅速进入问题解决模式，但有时候没有解决方案才是最好的而解决方案。许多问题根本不需要解决，看似问题是因为我们只关注表面症状。

学会审视问题本身。

看看能否改变问题。

我们必须戒除“问题解决迷恋症”。

89、打造上手的系统

我们十工具的制造者。我们制造的系统，一定要能够帮助人们——通常是其他人——做事，否则就是去了存在的意义，我们也将无法从中获取报酬。

用户体验应该是“上手的"。

90、找到并留住富有激情的问题解决者

组建一支汇聚优秀开发人员的团队，是确保软件项目成功非常重要的事情之一。一旦建成便竭力维护。

提放批评过度。批评过度，可能会扼杀开发人员的创造力，降低其生产力。更糟糕的是，可能会在团队内部造成纷争。

以正确的方式经营开发团队，其重要性不言而喻。