91、软件并非真实存在
软件工程经常被拿去和完善的传统学科——如土木工程——进行对比。这些类比有个问题，和这些传统实践制造的有形产品不同，软件并非真实的存在。
业务和软件都是活生生、会变化的实体。业务需求可能会因新近收购的业务伙伴和营销战略而迅速变化。
业务需求很可能会发生变化，因为我们构建的产品是柔韧的。
记住，需求文档不是蓝图，软件并非真实存在。我们创造的虚拟物比实体物更易于改变。
92、学习新语言
架构师必须让别人能理解你。
业务人员专业用语和程序员专业用语是有差别的。架构师需要掌握各个沟通团队的语言。
93、没有永不过时的解决方案
今天的解决方案会成为明天的问题。
今天做出的选择，在未来很大程度上是错误的。
“分析瘫痪”是今天架构师们碰到的问题之一，此问题最大的归因，是试图去猜测对未来而言最好的技术。
94、用户接受度问题
人们并不总是满心欢喜地接受新系统或系统的重大升级。这种情势，可能会对项目的成功构成威胁。
架构师的目标，是要去了解和衡量用户的接受度问题带来的威胁，并朝着能减轻这些威胁的方向开展工作。
“项目拥戴者”可以帮助消除用户接受度问题。这个职位的最佳人选，是能代表用户或利益相关方的人。
95、清汤的重要提示
清汤是一种非常清澈的肉汤，上品清汤非常清澈，需要不断重复的精炼浓缩才能烹出。
设计架构也应当不断精炼浓缩。
软件中许多漏洞的需求和缺陷，可最终追溯到含糊笼统的语言描述上。拒绝模凌两可的废话。概念需要在加上“总是、永远、不管任何情况下”仍然成立。
96、对最终用户而言，界面就是系统
糟糕的用户界面埋没了太多的好产品，最终用户通过界面访问系统。
架构师应该确保，随着架构变化而变的用户界面也要能够反应用户的期望。
不仅要让最常用的交互易用，而且要使最终用户能够从中获得回 。
97、优秀的软件不是构建出来的，而是培育出来的
在一开始就要设计庞大的系统几乎毫无好处可言。
设计尽可能小的系统，帮助成功交付，并推动它向宏伟的远景目标不断演化。
————————————————————————————————————————————————————————————————————————————
————————————————————————————————————————————————————————————————————————————
这本书深显易懂，里面的内容很多对于程序员都是已经接触过的，但写成优秀的程序就像不断的浓缩清汤（95条），以一种平凡的态度，不断的积累，终究会写出自己的那份华丽的简历。
其实这97条里面许多的都是重复的，毕竟一共大约有50位架构师的箴言，有些会写上好多条，同样的论点会被反复提起。不同的架构师也会提起类似的，那是不是重复就无用了呢，对于读者而言，正因为重复而加深印象，而变得更加重视。
粗略的从后面的十几个里面提取出以下几个方面：
数据：程序的核心就是数据，数据的结构表现出数据的形态，数据可能会随着架构更新，数据库也要更新。
文档：文档是为了避免反复思考而存在的，类似于代码注释，文档是对工程的注释。尤其是对架构师的每一个有可能产生分歧的决策，必须用文档标明决策原因。
推迟决定（也有其他翻译）：是软件开发模型的策略，这样有助于收集更多有关决定的信息。
团队：团队需要的不是单一的一类人，但需要的一起能合理分配工作并完成工作的一类人。找到好的团队成员一定尽心维护。
用户：客户至上，客户体验是架构师最好的简历，标志着软件的成功与否。
沟通：和业务部门沟通，需要学习业务部门的语言，其中涉及到一些专业词汇，避免沟通障碍。和客户沟通明白需求，和程序员沟通….
选择技术：如何选择使用的技术，要考虑的事项（如：架构师本人的技术，对于软件的性能，不同架构一起融合等）
性能：相对于功能而言，性能经常被忽略。
——————
当然还有其他，也应该还有本书未列入的内容。
——————————————————
共7篇博客，对于97件事都进行了简单的概括，原书本身也很简单，看过原书再看本博客效果最好。
其实概括本身就是对文章内容的抽象。
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！