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

61、数据是核心

软件开发人员最初将软件理解为命令、函数和算法构成的系统。

如果稍稍后退站远一点，计算机只不过是能访问与操作一堆数据的时髦工具。

代码在计算机中运行时，底层数据的状态不断发生变化。

举例而言，如果想了解Unix操作系统，通过源码逐行挖掘是不大可能奏效的，但是如果你读过一本unix内部数据结构的书，便可更好的了解unix底层是如何运行的。从概念上开看，数据比代码更加精炼，也更好理解。

即使对于最复杂的系统，通过这种面向数据的视角，即通过底层信息的结构整体开看待系统，也可以将之缩减为细节的有形集合。然后降低其复杂性。

数据在大多数问题中处于核心地位，业务领域问题由数据蔓延到代码中。

诚然，软件架构中的许多问题确实和数据相关。

从设计角度来看，大多数系统的关键问题，就是要在正确的时间从系统获取正确的数据。

62、确保简单的问题有简单的解

 软件架构师解决了许多非常困难的问题，但也会解决一些相对容易的问题，对于简单的问题，不要使用复杂的解决方案。

为复杂问题付出的直接成本可能看上去很小，但是其潜在成本要大得多。为问题的解决方案付出的代价不仅仅只是在实现和维护上。

架构师会从主观的判断或潜在不确定性需求出发，产生调整解决方案的强烈冲动。但记住一点：试图猜测未来的需求时，错的概率是50%，错的非常离谱的概率是49%。

63、架构师首先是开发人员

不管解决方案多么优秀，决定实现能否成功的最重要因素之一是让开发人员愿意接下任务。

虽然不是工作的一部分，架构师还是会经常去处理一些比较复杂的任务。这样做的目的有两个：第一，这是一种乐趣，而且还能帮我们做到宝刀不老；第二，这有助于向开发人员表明，我不是碰到麻烦时会干吹烟卷却束手无策的架构师。

64、根据投资回报率进行决策（ROI）

我们对项目所做的每一个决策——无论是技术、过程，还是与人相关——都可以看做一种投资形式。

回报率（rate of return），也成投资回报率（Return On Investment,ROI)，是衡量投资是否成功的标准之一。

将架构决策视为投资，并将相关的回报率也一并考虑在内。在判断每个决策选项是否务实或恰当时，这种方法很有用。

65、一切软件系统都是遗留系统

即使系统十分前沿，采用了最新的技术开发而成，但对接手它的下一个人而言，它也会是遗留系统（legacy）。必须面对这种情况！在今天，软件很快便会过时，这已经成为软件的天然属性。如果软件能够存活下来哪怕只有数月的时间，都必须承认一点：负责维护工作的开发人员肯定要对软件进行缺陷修复，这是不可避免的。这引出如下几个问题。

*清晰性：各个组件和类的角色一定要清楚

*可测行：系统易于验证吗？

*正确性：结果和设计或期望的一致吗？

*跟踪性：可容易修复紧急缺陷

66、起码要有2个可选的解决方案

对于某一个问题，如果只考虑了一个解决方案，那你就有麻烦了，在给定的约束条件下，寻找问题的最佳方案，期望第一个解决方案即满足全部的需求和约束，几乎是不可能的。

这种问题即使有——也绝少是真地由于缺乏可选方案而造成的，它更可能是架构师缺乏特定问题域的经验所致。

67、理解变化的影响

好的架构师能够将复杂性降到最低程度，他在解决方案中给出的抽象，应该能够为更高的层次提供坚实基础，同时，还应该能足够务实地应付未来的变化。

优秀的架构师能够深刻理解变化带来的影响，这种影响不仅限于彼此隔离的软件模块之间，而且包括人与人之间，以及系统与系统之间。

变化有多种不同的表现形式：

*功能需求的变化

*可扩展性需求的变化

*系统接口被修改

。。。。

幸运的是许多工具和技术可以用以减轻变化的影响：

*进行小规模的增量渐变

*构建可重复运行的测试用例

*跟踪好依赖关系

*降低复杂性

*自动化重复任务

68、你不能不了解硬件

对于许多软件架构师，硬件容量规划问题是一个超出其舒适区的主题，但它的确是架构师工作的重要组成部分。

如果没有硬件方面的专业知识，预估待开发系统的硬件配置是非常容易出错的。比起采购超出实际所需的硬件，为容量规划留出预算是更为经济的。

69、现在走捷径，将来付利息

长远看来，系统维护将比项目初期的开发消耗更多的资源。

测试：使用测试先行的设计，进行单元测试

碰到架构问题或设计缺陷，作为架构师，一定要坚持成本还很低廉时就动手。搁置越久，为之付出的利息也就越高。

70、不要追求完美，足够好就行

软件设计师，尤其是架构师，在评估针对某个问题的解决方案时，会倾向于考虑它是否优雅完美。有些瑕疵只须经由一些调整或迭代重构便可消除。

建议：不要屈服于企图使设计或实现达到完美的诱惑！把目的设定在“足够好”就行，当已经达成目标时就停下来。

71、小心“好主意”

“好主意”会杀死项目。有时候杀伤力会很快见效，但更常见的症状是：因屡屡错过的里程碑和不断攀升的缺陷数量，项目苟延残喘，最终不治身亡。

“好主意”：那种诱人2的、不用想都知道的、外表无辜、以为不可能会产生伤害的那种“好”注意。

“好主意”真正的邪恶之处在于它的“好”。

如果出现下列关键词，要小心了：

*如果....会更酷。

*“嘿，他们刚刚发布了YYY框架的XXX版本。我们应该马上升级”。

72、内容为王

我见过无数这样的设计，它们大都永无止境地强调需求、设计、开发、安全及可维护性，但从未关注系统的真正要点——数据。

73、对商业方，架构师要避免愤世嫉俗

雇主希望偶们能够解决问题，倾听和了解雇主的业务，是我们必须掌握的最为关键的技能。

成为优秀架构师的秘诀之中有一个关键要素，那便是:要对工作满怀激情，但不要是那种带着愤怒和火气的“激情”。

74、拉伸关键维度，发现设计中的不足

应用程序的设计轮廓，最初是基于特定的业务需求、所选择的技术或现有的技术、性能要求、预期的数据量，以及构建、部署和运营上可用的财务资源。无论采用什么样的解决方案，都要求能满足或超越当前环境下的要求，成功运行起来，否则这就不称其为解决方案了。

拉伸解决方案的关键维度，看看哪些方面会遭到破坏。

75、架构师要以自己的编程能力为依托

在架构上，架构师都期望能够创建出精巧的设计和完美的抽象，来优雅的解决手头的问题。如果能再项目中多安插些技术那就更让人有成就感了。但是最终要实现设计的不是架构师。如果开发人员需要去实现那些架构上的“杂技”，那将会对整个项目造成巨大影响

为项目设计架构时，对实现的每个设计元素所需要的工作量，要做到心中有数；如果以前曾开发过其中某种设计元素，那么估算所需的工作量将会容易得多。

不要在设计里面使用自己没有亲自实现过的模式，不要使用自己没有用之写过代码的框架，不要使用自己没有亲自配置过的服务器。