架构师不至于“架构”-《架构师应该知道的 37 件事》阅读笔记

这是我今年读完的第 2 本书。

这本书更合适的是传统企业架构师来看，不过对于长期在互联网公司环境下工作也很受启发。

以下是一些读书笔记：

架构师的多角色

• 架构师电梯，在“顶层套间”和“发动机房”之间往返。能理解公司战略并把它转为技术决策。

• 架构师像“强力胶”既懂得架构，又了解技术细节，还明白业务需求，而且能将大型组织和复杂项目的人员组织起来

• 按照需要扮演不同的角色，就可以成为一个优秀的架构师

架构师的三条腿：技能、影响力、领导力

• 技能是实践架构的基础。它需要知识以及应用知识的能力。

• 影响力用来衡量架构师在项目中应用技能后能给项目或公司带来多大的效益。

• 领导力确保了架构实践的状态能稳步向前推进，同时培养更多的架构师。

如何问正确的问题-“五问法”

• 一种找到根本原因的方法-五问法是由丰田佐吉（Sakichi Toyoda）提出的，是丰田产品系统的组成部分。是一种反复追问某些事情为什么会发生以便探究根本原因的方法。这种方法非常有用，但是人们常常会插入自己认同的方案或假设。

• 五问法案例：如果汽车启动不了，你应该一直追问“为什么”来找出根本原因：启动器无法点火，因为电池没电了；电池没电是因为车灯一直开着；车灯一直开着，是因为警告车灯一直开着的蜂鸣器没有发声；蜂鸣器没有发声，是因为一个电子设备出了问题。所以，你应该做的是修复这个电子设备，而不是去尝试通过跨接引线来启动汽车。

• 反复提问可能让回答者恼火，需要提前提醒同行，你不是在质疑他们的工作或者能力，而是在详细了解系统和问题。

跟着星巴克学架构设计

• 星巴克采用的是并行和异步的订单处理模型；前台不停的接收订单，咖啡师消费订单。当订单较多的时候，增加咖啡师可以缓解订单积压问题。

• 采用咖啡杯标记唯一标志解决饮品和顾客的关联问题；前台点单是在咖啡杯上标记序号或顾客名字，即是标记问题。

• 采用忽略、重试、补偿等操作解决异常问题；制作有问题的咖啡直接倒掉，然后重做一杯。无法制作出满意的咖啡就退款等。

• 咖啡的交互很优秀、简单直接，使用的是尽可能“短会话”的模式。顾客和前台进行一个简单的同步交互（下单和付款）然后把需要较长时间的（制作和拿到饮品）作为异步交互。

• 咖啡定义了专用语言，规范化数据模型；比如小杯咖啡叫“中杯”，大杯叫“超大杯”。使用统一的语言，优化上下文流程，顾客、收银员、咖啡师采用统一语言进行交互，提高写作效率。

包含关键决策的架构图才是好的架构

• 左侧：这个房子是当前大多数架构师所画的架构图，主要包括需要的组件和组件之间关系

• 右侧：除了包含基本组件和组件之间关系还包括一些关键决策；

• 架构决策过程：无论如何，请务必记录决策背后的具体原因以及折中后的最终结论。

• The Open Group 为开放组体系结构框架（TOGAF）选择了其中的一个变体：组件的结构、组件的相互关系，以及管控组件设计和长期演进的原则和指导方针。

• Desmond D'Souza 和 Alan Cameron Wills 的大作：有关任何系统的设计决策，能让实现者和维护者免于不必要的创造行为。

• 架构的核心是基于知识的决策，不是止步于做所有可能的技术方案的发现者。

一些架构原则

• 让一切自动化。不能自动化的，就做成自助服务。DevOps 所倡导的

• 像测试驱动开发不是一种测试技术（它主要是一种设计技术）一样，自动化也不只和效率相关，而主要和可重复性以及弹性相关。

架构师如何做好沟通

• 减少学习的“陡坡”。构建一个逻辑顺序以便让受众能够在他们不熟悉的领域得出结论。同时避免在逻辑上的间隙和跳跃

• 基于一个具体的词汇表建立基础心智模型，这个心智模型不需要特别正式，重点是让受众能够在讨论的不同的元素之间建立联系

• 在讨论时需要在选择合适的细节层次，同时也需要注意在过程中要始终同一细节层次。这也是在“抽象”时需要注意的一点，保证“抽象”在同一层次，比较困难但是一定要做到这一点

• 尽量通过写文档沟通；好文档像动画片《怪物史莱克》，受众广，用故事标题取代概要，使用图，使用特殊标注标记重点或者一些细节（非重点）。

• 文档或者绘图时不要面面俱到，要突出重点；3 秒测试法，让受众看 3 秒明白重点在哪里；

• 使用图形描述架构全貌

组织 &转型的一些记录

• 敏捷方法是通过频繁的重新校准和拥抱变化达成正确的目标，而不是试图预测环境和消除不确定性

• 把系统和组织的设计都看作一个迭代的，由业务价值驱动的动态过程。

• 关注流程而非过于追求单点效率。

• 大多数数字化公司的核心元素：持续学习循环。即构建-衡量-学习循环：公司构建并发布一个最小可行产品来衡量用户的使用行为，然后学习和分析实际产品使用的数据，进而改进产品。

• 架构师的工作扩展到了很多方面，不仅要设计新的 IT 系统，而且要设计与系统匹配的组织结构和文化。

• 质量是什么？质量不再是定义好的软件需要符合的规范而是从用户视角，用户真正所想要的系统。数字化公司里不会假设用户需要什么，而是通过观察用户的行为，快速调整和改进产品。进而让用户满意。

• 组织的主要竞争资产是自身的快速学习能力。映射到软件设计就是快速迭代能力。

附录：《架构师应该知道的 37 件事》的“读书档案”

1. 阅读此书的目的

• 增进对于架构师的认识，了解企业架构师的角色以及关键的能力。

• 了解架构师如何做关键决策以及和各个角色的沟通

• 了解架构师在企业的价值

1. 读书后的感受

• 架构师不至于“架构”。除了在技术上具备丰富能力，还要在沟通、组织以及企业转型上有自己的认识和方法

• 包含关键决策的架构图或架构文档才是好的架构文档

• 架构师需要具备化繁为简的能力，通过“故事”等简化复杂的概念，学会和各方沟通

• 新型数字化公司即构建构建-衡量-学习循环

1. 阅读此书后，接下来打算做些什么

• 继续学习有关架构师的书籍，增进对于架构师的认知

• 从多个角度思考和看懂工作中遇到的架构问题。在所写的技术文档中，采用书中的方法做审视、校验

• 应用“沟通”相关的技巧，减少后续文章中读者的学习的“陡坡”

1. 3 个月后，打算做些什么，有什么样的改变

• 阅读 5 本以上关于架构相关的书籍

• 争取形成架构师的知识图谱，构建自己成长路线图争取

• 发表 3 篇以上关于架构相关的博文