读《软件架构师应该知道的 97 件事》

 

掌握业务领域知识

要懂技术，要掌握问题空间对应的业务领域知识。

架构师的角色任务在于理解业务问题、业务目标、业务需求，并设计技术架构来满足它们。

比如：保险行业适合采用面向服务的架构方法，而金额市场适合采用基于工作流的架构方法。

能自如地运用企业高管（C-level executives）和用户熟悉的行业术语与他们沟通。

更好的理解要解决的难题、有争议的问题、业务目标，以及数据和流程。这是设计有效企业架构的关键因素。

 

程序设计是一种设计

程序设计是学习的过程。看作发现和学习的过程，而不是生产和建造的过程。

如果要发展实践方法，软件行业应该到哪里取经呢？可以参考汽车、医药和半导体这些生产大众产品的精密行业。

如果把编写代码看成设计行为，而不是生产行为，就能采用一些已经被证明有效的管理方式。这些方法过去用于管理具有不可预测性的创新工作，比如研发新车、新药、新的电脑游戏。

程序设计是设计范畴。

 

让开发人员自已做主

 

时间改变一切

以更简单的方法来完成。

 

别跟以前的工作过不去

你看重的设计思路，可能两三年后就会被自己否定，更不要说十年。当你回顾过去的工作时，永远会觉得以前的设计和自己的期望有差距。学着接受以前的工作吧，克制自己回过头去修改的冲动。

 

软件开发仍然处于相对初级的尝试阶段，我们对它的了解还相当不够，不足以将其专业化。

 

控制项目规模

架构师不是演员，是管家

花的是客户的钱。

 

软件架构的道德责任

软件的用户友好性设计

 

摩天大厦不可伸缩

性能至上

 

决定程序流程的不是调用堆栈（call stack），而是用户需求。

《企业集成模式：设计、构建及部署消息传递解决方案》

记录决策理由

《取舍的艺术》

这类文档迟早会派上用场，比方说：

• 可以作为和开发人员进行沟通的工具，说明应遵循的重要架构原则。

• 当开发人员对架构背后的逻辑提出质疑时，使团队成员能够“就事论事”，甚至能够避免一场“兵变”（如果事实表明你的决策站不住脚，便应虚心接受批评）。

• 向经理和利益相关者说明这样构建软件的确切原因（比如，采用某种较为昂贵的硬件或软件的必要性等）

• 要把项目移交给下任架构师时（你有多少次在接手软件时很疑惑原来的设计者究竟为什么要采用那种做法？）

好处：

• 它逼着你明确说出理由，有助于确保基础是扎实稳固的

• 如果相关条件发生变化，需要对决策重新评估，它可以作为一个起点。

 

分享知识和经验

讨论有助于发现不足。只有能非常容易地做出解释，才表明你真正理解了。只有不断解释和讨论，才能把经验凝聚成知识。

 

关注应用程序的支持和维护

理解开发人员和支持人员确实有不同的技能

从“可行走骨架”开始，保持系统一直运行可用。

 

数据是核心

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

在某种抽象意义上，可以认为任何算法都只是数据从一个版本到另一个版本的迁移（transformation）而已。

功能视为是“更多定义良好的迁移所构成的集合”，在多个版本间连续推动数据的流动。

 

简单问题都有简单的解

sku ( stock keeping unit，最小存货单位)

 

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

应用程序的设计轮廓，最初是基于特定的业务需求、所选择的技术或现有的技术、性能要求、预期的数据量，以及构建、部署和运营上可用的财务资源。

架构师可以通过拉伸线维度，对解决方案进行校核。

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

坦然面对客户在预算和时间上给出的约束。

要做能提升架构师效率的工作，而不仅仅只是做自己喜欢的工作。

坚持贯彻使用的过程和方法学。

承担责任。

《精进不止：手术室中的沉思》

成功需要的是勤奋，清晰的道德观念，创造力，而不是极高的天分。最重要的是你必须有不断尝试的信念。

    书译名：《一位外科医师的修炼》《开刀房的沉思——一位外科医师的精进》

成为异数的五个方向：

随口问问，别猛吐苦水，找目标计数，勤于写作，勇于改变。

 

 

这本书是近期写的笔记最多的一本了。收获不说大不大。但细节的记录到是真多。