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

91、软件并非真实存在

软件工程经常被拿去和完善的传统学科——如土木工程——进行对比。这些类比有个问题，和这些传统实践制造的有形产品不同，软件并非真实的存在。

业务和软件都是活生生、会变化的实体。业务需求可能会因新近收购的业务伙伴和营销战略而迅速变化。

业务需求很可能会发生变化，因为我们构建的产品是柔韧的。

记住，需求文档不是蓝图，软件并非真实存在。我们创造的虚拟物比实体物更易于改变。

92、学习新语言

架构师必须让别人能理解你。

业务人员专业用语和程序员专业用语是有差别的。架构师需要掌握各个沟通团队的语言。

93、没有永不过时的解决方案

今天的解决方案会成为明天的问题。

今天做出的选择，在未来很大程度上是错误的。

“分析瘫痪”是今天架构师们碰到的问题之一，此问题最大的归因，是试图去猜测对未来而言最好的技术。

94、用户接受度问题

人们并不总是满心欢喜地接受新系统或系统的重大升级。这种情势，可能会对项目的成功构成威胁。

架构师的目标，是要去了解和衡量用户的接受度问题带来的威胁，并朝着能减轻这些威胁的方向开展工作。

“项目拥戴者”可以帮助消除用户接受度问题。这个职位的最佳人选，是能代表用户或利益相关方的人。

95、清汤的重要提示

清汤是一种非常清澈的肉汤，上品清汤非常清澈，需要不断重复的精炼浓缩才能烹出。

设计架构也应当不断精炼浓缩。

软件中许多漏洞的需求和缺陷，可最终追溯到含糊笼统的语言描述上。拒绝模凌两可的废话。概念需要在加上“总是、永远、不管任何情况下”仍然成立。

96、对最终用户而言，界面就是系统

糟糕的用户界面埋没了太多的好产品，最终用户通过界面访问系统。

架构师应该确保，随着架构变化而变的用户界面也要能够反应用户的期望。

不仅要让最常用的交互易用，而且要使最终用户能够从中获得回报。

97、优秀的软件不是构建出来的，而是培育出来的

在一开始就要设计庞大的系统几乎毫无好处可言。

设计尽可能小的系统，帮助成功交付，并推动它向宏伟的远景目标不断演化。

————————————————————————————————————————————————————————————————————————————

————————————————————————————————————————————————————————————————————————————

这本书深显易懂，里面的内容很多对于程序员都是已经接触过的，但写成优秀的程序就像不断的浓缩清汤（95条），以一种平凡的态度，不断的积累，终究会写出自己的那份华丽的简历。

其实这97条里面许多的都是重复的，毕竟一共大约有50位架构师的箴言，有些会写上好多条，同样的论点会被反复提起。不同的架构师也会提起类似的，那是不是重复就无用了呢，对于读者而言，正因为重复而加深印象，而变得更加重视。

粗略的从后面的十几个里面提取出以下几个方面：

数据：程序的核心就是数据，数据的结构表现出数据的形态，数据可能会随着架构更新，数据库也要更新。

文档：文档是为了避免反复思考而存在的，类似于代码注释，文档是对工程的注释。尤其是对架构师的每一个有可能产生分歧的决策，必须用文档标明决策原因。

推迟决定（也有其他翻译）：是软件开发模型的策略，这样有助于收集更多有关决定的信息。

团队：团队需要的不是单一的一类人，但需要的一起能合理分配工作并完成工作的一类人。找到好的团队成员一定尽心维护。

用户：客户至上，客户体验是架构师最好的简历，标志着软件的成功与否。

沟通：和业务部门沟通，需要学习业务部门的语言，其中涉及到一些专业词汇，避免沟通障碍。和客户沟通明白需求，和程序员沟通....

选择技术：如何选择使用的技术，要考虑的事项（如：架构师本人的技术，对于软件的性能，不同架构一起融合等）

性能：相对于功能而言，性能经常被忽略。

——————

当然还有其他，也应该还有本书未列入的内容。

——————————————————

共7篇博客，对于97件事都进行了简单的概括，原书本身也很简单，看过原书再看本博客效果最好。

其实概括本身就是对文章内容的抽象。