软件架构-读书小记

架构师真正要学会的事情

• 要学会去看，然后忘掉；
• 要学会去听，然后忘掉；
• 要学会去做，然后忘掉；
• 要学会超越；

• 既有知道的、理解的、明白的，形成了我们的知识与行为的一切，却也正是阻碍我们前进的东西；

• 架构师会贡献代码、参加代码评审/回顾，有预先架构设计、也有架构演进，执行scrum，任何对设计有意见都可以提出来；
• 关于软件架构；

• 软件架构应该容易被理解；
• 所有软件项目都需要架构；
• 传播轻量级软件架构实践；

• 软件开发的新方法： 传统软件过度的预先设计，而初次接触敏捷方法的团队往往缺乏架构思维，两者之间找到一个平衡点；
• 关于软件架构，开发者知道的事；

• 软件架构不是大型预先设计；
• 每个软件团队都需要考虑软件架构；
• 软件架构的角色关乎编码、指导和合作；
• 无需使用UML,轻量级的”框线“风格的草图；
• 好的软件架构师支持敏捷开发的；

1 什么是架构

• 名词：将产品分解为一系列组件、模块和交互；
• 动词：你需要构建什么、设定愿景以便于进行构建和做出恰当的设计决策；需求驱动架构；

2 架构的种类

• 共同点：结构和愿景；任何成功的方案都需要你理解问题，并设定一个愿景可以和每个参与构建最终产品的人沟通。

3 软件架构是什么

• 应用程序架构：注重考虑软件和代码组织；
• 系统架构：更大规模的应用程序架构，组合单独的应用程序；
• 软件软件：从代码结构和基础到将代码成功部署到生产环境，与软件系统重要元素相关的所有东西就是软件架构；
• 企业架构：整个组织的中心工作，着眼于如何组织与利用人员、流程和技术来使企业有效和高效的工作；需要更高层次的抽象，应广度而非深度，关乎战略而非代码；

4 敏捷软件架构

• 敏捷：

• 软件开发的敏捷方法：快速行动，拥抱变化，持续交付，接受反馈，不一而足；
• 敏捷环境工作： 团队动态，系统思维，心理学及其他可能会跟创建高效团队练习在一起的事情；

• OODA: 观察，定向，决策，行动；
• 敏捷是相对的，且按时间来衡量，如果你的团结团队交付的软件跟不上所处的环境变化，就不算敏捷；
• 好的架构带来敏捷：软件系统由小型微服务构成增长趋势，每个服务只专注做好一件事；小型、松耦合的组件和服务可以孤立的构建、修改和测试，甚至根据需求变化移除和替换；
• 不同的软件架构提供不同层次的敏捷，介于整体架构和微服务架构之间；

5 架构对上设计

• 设计是指一个系统内命名的结构或行为，解决或有助于解决该系统一个或多个问题，设计代表了潜在的决策空间中的一个点；
• 所有的架构都是设计，但并非所有的设计都是架构；
• 重要决策都是架构，其他都是设计，架构决策不可能轻易反悔，大费周章；

6 软件架构重要

• 软件架构的好处：

• 让团队跟随一个清晰的愿景和路线图；
• 技术领导力和更好的协调；
• 与人交流的刺激因素，以便回答与重要决策、非功能需求、限制和其他横切关注点相关的问题；
• 识别和减轻风险的框架
• 方法和标准的一致性，随之而来的结构良好的代码库；
• 正在构建的产品的坚实基础；
• 对不同的听众，以不同层次的抽象来交流解决方案的结构；

• 所有软件项目都需要软件架构？

• 肯定的，每个项目考虑多种因素，以评估必需多少软件架构的思考；

7 问题

• 架构说些什么？

• 见 1；

• IT领域有很多不同类型的架构，共同之处？

• 共同点：结构和愿景；任何成功的方案都需要你理解问题，并设定一个愿景可以和每个参与构建最终产品的人沟通。

• 软件架构的标准定义？

• 软件软件：从代码结构和基础到将代码成功部署到生产环境，与软件系统重要元素相关的所有东西就是软件架构；

• 敏捷来描述软件架构什么意思？

• 见5

• 企业架构师你的出路吗？

• 需要更高层次的抽象，应广度而非深度，关乎战略而非代码；

• 软件架构重要吗？为什么，好处？

• 见6

软件架构的角色

8 软件架构的角色

• 循序渐进的过程，获得这个角色所需的经验和信心；
• 这里的角色可以是一个人，也可以由软的共同扮演；
• 1 架构驱动力：理解目标：抓住、提炼、挑战需求和限制；
• 2 设计软件：建立技术战略、愿景和路线图；

• 技术选择；练习

• 3 技术风险：发现、减轻和承担技术风险，保证架构的运转；

• 技术选择就是风险管理，技术决策需要评审和评估；

• 4 架构演化：贯彻整个软件交付过程，持续的技术领导和对架构的 承担；
• 5 编写代码：参与到软件交付的实践部分；
• 6 质量保证：引入并坚持标准、指导、原则等；

• 代码评审；

• 技术领导是一个角色而非级别
• 提出你对这个角色的定义；

• 软件架构的必要性是，角色的责任不明确；

9 软件架构师应该编码

• 软件架构师应该编码，需要抽象的思维能力，可以理解成不把所有时间都耗在细节里的能力；
• 编写代码

• 把自己当成软件开发团队的一份子，一顶软件架构的帽子和一顶编写代码的帽子；
• 创建能实际实现的软件架构，和团队建立融洽的关系；

• 构建原型、框架和基础；
• 进行代码评审；
• 实验并与时俱进

• 不断学习技术知识，才可进行方案设计；工贡献开源，到尝试语言，框架，api等；

• 软件架构师和雇主的矛盾

• 坚守好自己的立场；

• 不必放弃编码，且不要把所有时间都用于编码，关注实现细节；

10 软件架构师应是建造大师

• 误解：敏捷方法，减少预先思考的工作量，架构师只做高层次的抽象思维，ppt架构师，象牙塔架构师；
• 架构师直译为首席建筑师；经历石匠历练；渐进的过程，从学徒，到帮工，到大师；软件开发行业缺乏明确的路线；
• 要和团队一起工作；

11 从开发者到架构师

• 软件架构师和架构之间的界限，尽可能的抽象，不拘泥于实现细节
• 经验是一个号的评价标准，但需要看的更深；

• 1 架构驱动力：挑战一套复杂的非功能性需求；
• 2 设计软件：
• 3 技术风险
• 4 架构演化：
• 5 编写代码：
• 6 质量保证：

• 模糊的界限，跨越式我们的责任，给一个系统的架构出力和为之负责，清楚自己的经验水平，提升他们需要关注什么；

12 扩展T

• 进一步的技术能力，T是技术，如何语法，api，框架，设计模式等；
• 软件专业人员只精通一到两项的技术，奴隶保持开放的思维；
• 知识面宽；

• 和其他可选技术比，我们所选的是否合适；
• 还有哪些更多选择；
• 是否该采用通用的架构模式；
• 是否明白决策的利弊；
• 非质量属性；
• 如何证明架构行之有效；

• 软件机构是是通才型专家；

• 合作才是关键，找到那些知你不知的人，紧密合作，结对编程到结对架构；

• 软件架构师技术活：深度与广度并存的知识组合，及软技能；

13 软技能

• 领导力：创造共有的愿景，带领人们向目标前行的能力；
• 沟通；
• 影响力：好的倾听和探索；
• 信心；
• 合作；
• 指导；
• 辅导；对人学习方面的指引，非告诉他们怎么做一件事；
• 动力：保持团队愉快、开朗、积极；
• 润滑剂
• 政治：远离；
• 责任感；
• 授权；适当的时候授权；
• 保持积极；领导的角色，有影响力的位置，正能量的热情带动团队；

14 软件架构不是接力运动

• 解决方案架构师，技术架构师，为自己方案写文档，扔给单独的开发团队；架构即服务；Aaas；
• 有人负责大局，创建最初的愿景，交流，并在真个软件开发的生命周期潜在的演化它，保证软件顺利交付承担责任； 软件开发不是接力运动，顺利交付也不是实现细节；

15 软件架构需要引入控制吗

• 提供指导，追求一致性；
• 引入的控制量；一种独裁，一种放手；
• 控制因文化而不同，不同国家和文化对控制的看法不同；
• 操纵杆，而非按钮；两者之间可以调整；先从部分控制开始，倾听反馈；如果团队老是问，为什么和怎么办，需要更多指导；如果团队好像总是在和你对着干，可能就是你操纵杆推的太多，需要调节；

16 小心鸿沟

• 开发者关注底层细节；
• 闭门造车的独裁架构师；
• 拉近距离；开发团队不尊重架构师，缺乏积极性，无人负责；
• 架构师：

• 包容与合作，让团队参与架构的过程；
• 动手；参与日常开发，提供对架构交付的理解；

• 开发者

• 了解大局，花时间了解做出架构决策的语境，增强对系统的理解；
• 挑战架构决策；合作店 过程；
• 申请参与：参与进来，提出来；

• 软件架构的合作方式；减少鸿沟，合作；

17未来的架构师

• 指导、辅导、和师徒的关系；
• 失去技术导师：企业晋升，被迫离开技术岗就是资深的技术人员；
• 软件团队需要休息：为了提供，需要时间远离日常工作，进行思考；编码经验容易积累，但是从头开始设计需要教授和实践；

18 人人都是架构师

• 集体代码所有制，团队任何人都有权改动代码；
• 自组织团队作为努力的方向

• 生存型（混乱）：需要一种之间只会和控制的领导风格；
• 学习型：需要一种指导的领导风格；
• 自组织性：需要简易化来确保平衡不受影响；

• 需要一个人来承担软件架构角色的责任；
• 敏捷需要架构吗？

• 与敏捷对立的不是架构，而是大型预先设计；
• 敏捷项目仍然需要架构，知识对架构角色的执行不同；
• 一个人承担责任还是团队共同分担，无论敏捷与否，软件架构的 角色还是存在的，只有所处语境才会告诉你正确答案；

19 软件架构咨询师

• 领域知识；
• 权威：

• 软件架构角色引入多少控制，取决于工作的团队类型；
• 技术领导力；
• 决策权；

20 问题

• 软件架构和软件开发角色的区别？

• 更多的时经验，
• 1 架构驱动力
• 2 设计软件：
• 3 技术风险
• 4 架构演化：
• 5 编写代码：
• 6 质量保证：

• 软件架构的角色都做些什么？

• 同上

• 为什么承担软件架构角色的技术很重要？

• 见12；

• 如果你是项目的架构师，编码的工作比例？

• 应该编码，不必放弃编码，且不要把所有时间都用于编码，关注实现细节；

• 为什么知识的深度和广度都很重要？

• 见12

• 软件架构的软技能，哪些还未掌握？

• 见13

• 软件架构的角色如何融如敏捷项目和自组织团队；

• 见18；

设计软件

21 架构驱动力

• 功能需求

• 对需求还没高层次理解，就设计甚至构建软件，特性或用户故事必不可少，需求驱动架构；

• 质量属性

• 非功能需求代码的质量属性反应了服务等级，如性能、可伸缩性、可用性、安全性等；

• 约束
• 原则

• 约束通常都是强加于你的，而原则是你为了将一致性和清晰度引入最终代码库而采用的原则或架构原则；

• 理解影响：要开始设计选型，是你所需知识的基本水平

• 首先了解这些东西可以帮助减少摆在你面前的可选项；
• 其次，根据特定的目标和语境，做出明智的设计决策；

• 软件架构谈论的时重要的设计决策，其重要性以变动的成本来衡量；封装变化；

22 质量属性（非功能性需求）

• 性能：rt，延迟
• 可伸缩性：
• 可用性；
• 安全性；
• 灾难恢复；
• 可访问性；
• 监测
• 管理
• 审计：引起软件数据或行为变化的事件的日志；
• 灵活性；
• 可扩展性；功能性；插件和api
• 可维护性
• 法律法规
• 国际化（i18n）
• 本地化（i10n）

23 处理非功能性需求

• 捕捉：客户给出的很少，主动出击，捕捉他们，反问出质量属性是否接受；
• 提炼
• 挑战

• 如果你问人们是否需要一个东西，回答肯定是；只有尝试划分优先级，每件事最后都会变成不可或缺；
• 提出成本的影响有助于集中注意力；
• 你需要构建一个正常运行时间100%，必须消灭每个故障点，所有的花费翻一番；可以做，但是成本很高；

24 约束

• 时间和预算的约束
• 技术约束

• 批准的技术清单
• 现有系统的互操作性；
• 目标部署平台；
• 技术成熟度
• 开放源代码
• 供应商关系
• 过去的失败；
• 内部知识产权；

• 人员约束
• 组织约束
• 约束也可以划分优先级
• 倾听约束；

25 原则

• 开发原则

• 编码标准和规范
• 自动化单元测试；
• 静态分析工具；

• 架构原则

• 分层策略；
• 业务逻辑的位置；
• 高内聚低耦合，solid
• 无状态组件；
• 存储过程
• 域模型，丰富与贫瘠
• HTTP会话的使用
• 始终一致与最终一致性；

• 谨防最佳实践

• 构建软件的大小和复杂度，加上环境的约束，帮助你决定采用哪些原则，倾听团队成员的反馈也能帮助 你认清你的原则是否奏效；

26 技术不是实现细节

• 架构图应该包含技术的选择，很多说 可以用任何技术构建，不意味如此，原因

• 你有复杂的非功能性需求吗
• 你有约束吗
• 你有一致性吗？缺乏一致性的方法会导致代码库难以理解，维护和增强；

• 推迟或解耦：解耦很好，但不应该推迟
• 每个决策都是权衡
• 如果你不明白选择X技术而非Y的权衡，你就不应该做决策，理解，牺牲了啥；

27 更多的分层等于更高的复杂度

28 协同设计是一把双刃剑

• 整个团队的高效取决于很多因素，其中之一是克制自负的情绪，专注于交付给定语境下的最佳解决方案；

• web开发：给我json格式的数据；
• 服务端：我把全部数据发到web层更安全；
• 数据库：不管你们要啥，我都写一个存储过程搞定；

• 经验影响软件设计

• 我们拥有的知识、经验和偏好影响我们的软件设计方式，
• 合作，也就是相互沟通和挑战；
• 结对编程；

29 软件架构是对话的平台

• 软件开发要定期与最终用户沟通，才能确保我们构建的软件符合他们的需要；反馈；
• 软件开发不只是交付特性；

• 软件开发不是闭门造车，软件设计过程是一个交流的平台，五分钟的交流有助于捕捉那些不起眼的架构驱动力，提高成功交付的机会；

30 sharepoint项目需要软件架构

• 企业信息管理方案

• 很多sp实现度不只是sp，新旧技术的结合体，复杂的集成；
• 非功能性需求；
• 技术领导力；
• 编写文档；

• 强大的领导力和记录不只是针对软件开发项目；

31 问题

• 影响软件架构最终架构的主语因素是什么？

• 架构驱动力，见21；

• 什么是非功能性需求，为什么重要？

• 见22，反应了服务等级；

• 时间和预算是立刻想到的约束，还有更多吗？

• 见24

• 你的软件是否用了知名的架构原则？

• 见25 架构原则；

可视化软件

32 沟通障碍

• 可视化软件，抛弃UML，用一套简单图标，各自只展示整个故事的一部分，不适用UML时要密切关注图标元素；
• 敏捷需要良好的沟通；

33 对草图的需要

• 测试驱动开发与图标，在视图找到解决方案之前，先将问题可视化；
• 可视化问题的一个方法是提问，搞清楚我是否明白你在说啥什么？
• 为什么学习画草图？ 敏捷需要良好的沟通；
• 画草图不是艺术，不是综合模型；不是谈论细节，有效且高效的交流你正在构建的软件架构；
• 画草图可以是协作活动；

34 无效的草图

• 只有框没有线；
• 太多假设；
• 有效的草图：一些简单的建议和一组通用的抽象；

35 C4 语境、容器、组件和类

• 通用的抽象集合：软件系统由多个容器构成，容器由多个组件构成，组件由多个类实现；
• 类：软件系统的最小结构单元；少量的UML图；
• 组件：可以想象成一个或多个类组成的逻辑群组；每个容器的关键逻辑组件及之间的关系；
• 容器：一个其内部可以执行组件或驻留数据的东西；高层次的技术选择；
• 系统：系统是最高的抽象层次，代表了能够提供价值的东西； 设置场景的高层次图；

36 语境图

• 意图：构建的软件系统是什么？ 谁会用它？ 如何融入已有的IT系统？
• 结构：中间框图展示你的系统，周围是它与其他之间相互作用的系统；
• 动机：语境更明确，是其他图表的起点；
• 例子： 用户（管理、业务用户），系统（上下游依赖）

37 容器图

• 高层次的技术选择
• 意图：软件系统的整体形态，技术决策时哪些？
• 容器：web服务器，应用服务器，数据库等；
• 交互：进程间通信，交互的目的，通信方法，方式，协议和端口号；

38 组件图

• 进一步分解每个容器，鉴别逻辑组件及其交互
• 意图：系统由哪些组件/服务构成？
• 结构：逻辑组件的图，麻将图；
• 组件：认证服务，日志服务，检测服务，系统导入器等；

39 是否包含技术选择

• 大部分架构图湖绿了任何有关技术的信息，专注于说明功能分解和注意概念元素，为什么不展示任何技术决策？属于实现细节？最后责任时刻原则？
• 架构图本质上需要概念化，架构名声不好，闭门造车刻板印象的高层次图；
• 技术选择不应该是实现细节，确保技术得到考虑就是引入架构图，可以消除歧义，可以使用容器图单独展示技术决策；

40 你会那样编码？

• 共享组件，确保图能反应；
• 分层策略；
• 图应该反映现实，而不是对不存在的进行概念化表现，图的元素可以反映在代码库中；

41 软件架构和编码

• 职责驱动设计和组件分解
• 好的组件和好的 类有一些共性，应该高内聚、低耦合，有良好的定义的公共接口，良好的封装等；
• 经常谈论组件，但编写类； 架构图和代码映射有巨大差异；
• 用分层来结构化代码；用层来组织代码库使团结的整体结构更易观察；
• 用特性封装；业务领域相关的东西；
• 用组件封装； 微服务，只有自己内部的层和配置；内部的 作用域在内；
• 软件架构和编码需要一致；架构风格需要反映在软件架构图中；

42 你不需要UML工具

• 是否使用uML不是黑白分明的；有效简单使用白板，到位的UML图依然帮你呈现一个软件系统中复杂和详细的元素；流程和工作流、运行时行为、域模型、模式和原则、状态图、部署；

43 有效的草图

• 标题
• 标签
• 形状
• 职责
• 线条；
• 颜色
• 边框
• 布局：便利贴；
• 方向
• 倾听问题，收集反馈；

软件生成文档

46 代码不会讲述完整的故事

• 追求易于阅读、理解和维护的好代码；
• 代码未描述的设计意图、问题；
• 辅助信息；轻量级的辅助文档；

47 软件文档即指南

• 敏捷可以工作的软件重于面面俱到的文档； 对最终用户来说真正工作的软件有价值，不是不写任何文档；代码不会讲述完整的故事，缺少关于复杂软件系统的辅助信息源会让团队在努力浏览代码拖累；
• 软件软的有义务和代码库一起交付一些辅助文档；
• 语境
• 功能性概览
• 质量属性
• 约束
• 原则

• 架构分层策略
• 视图中没有业务逻辑
• 视图中没有数据访问
• 接口的使用
• ORM
• 依赖注入
• 好莱坞原则
• 高内聚低耦合
• SOLID
• DRY
• 组件无状态
• 富域模型
• 贫血模型
• 存储过程是否使用
• 不重复造轮子
• 错误处理、日志等通用方法；

• 软件架构
• 外部接口
• 代码
• 数据：数据模型
• 基础设施架构
• 部署：软件和基础设施之间的映射
• 运营和支持：人们如何运行、监测和管理你的软件；
• 决策日志

开发生命周期中的软件架构

62 敏捷和架构的冲突

• 架构就是结构和愿景，关键在于理解重要设计决策；
• 敏捷项目需要架构；
• 1 团队结构

• 减少用文档传递来沟通产生的管理开支；加强合作减少浪费；

• 流程和产出

• 快速行动，接受反馈，拥抱变化，随机应变不是依计划行事；

• RDD/BDD/DDD/TDD: 责任/行为/领域/测试
• 大型预先设计，往往想得太多；
• 软件团队剔除炒作，理解技术领导力的方式，在器独特的环境下量化所需要的预先设计；

63 量化风险

• 识别风险是恰如其分的预先设计的关键的部分；
• 概率与影响；
• 设定风险的优先级；

64 风险风暴

• 风险风暴是一种快速、有趣、协作和视觉的风险识别技术；
• 步骤1：画一些架构图；
• 步骤2：分布识别风险；5-10分钟，保持沉默；
• 步骤3：汇总图中的风险；
• 步骤4：对风险设定优先级；风险的理由，概率和影响；
• 缓解策略：

• 教育：训练团队，重组团队；
• 原型：
• 修订；

65 恰如其分的预先设计

• 瀑布式，大型预先设计；敏捷；演化架构和浮现式设计；
• 做到恰如其分：很难量化；
• 太少：不了解系统边界，未确认的重大问题和决策等；
• 太多：太多文档，过于死板，分析瘫痪等；
• 多少是恰如其分的： 衡量的重要性：改变的成本；结构、风险、愿景；
• 把恰如其分的预先设计置于适当的语境； 多实践；

66 初始软件架构

• 软件架构应该容易理解；
• 实用的建议：

• 宣传教育，专题活动；
• 回顾架构；
• 完成标准；项目的标准包含软件架构；
• 分配软件架构角色；
• 架构培训班；

• 推动变革的发生

• 没时间实践；
• 被动型：情况变糟时候改变工作方式；
• 主动型：积极改进工作方式，花时间没得到管理层认可；
• 非常清晰和简洁的方式陈述当前的状况，如果不改变，会有哪些问题，风险和后患；
• 以身作则，发现把那个解决问题，包含缺乏技术文档；积极主动引入软件架构；