1. 概况
书名：《程序员必读之软件架构》
时间：20250704～20250731
这本纸质书放在家里时间挺长，之前看着目录比较简单，一直没有去翻阅。
近来看完其它书，偶然翻阅，别有一番风味：行文比较简单。
印象深刻的两部分内容是『画图』和『文档』。
特别是文档，有一个很好的类比：旅游指南/攻略 VS 软件指南。
- 随说：软件指南 VS 旅游指南
一句话概况：架构代表了重大决策，衡量重要性的则是改变的成本。
文章最后有更多架构相关书籍的读后感链接。
1.1 什么是架构？
名词解释：将产品分解为一系列组件、模块和交互。
动词解释：理解你需要构建什么、设定愿景以便进行构建和做出恰当的设计决策。
- 本质：结构 + 愿景
- 现象：需求驱动架构
1.2 架构的好处
1.2.1 没有架构会怎么样？
如果没有人思考软件架构，最终结果往往看起来像一团乱码。
副作用包括软件系统难以维护、难以改变、难以扩展、难以部署、太慢、不安全、脆弱、不稳定等等。
1.2.2 架构的好处
- 让团队有清晰的愿景和路线图；
- 技术领导力和更好地协调；
- 更好地回答重要决策、非功能需求、限制和其他问题；
- 识别和减轻风险的框架；
- 方法和标准的一致性(结果之一：结构良好的代码库)；
- 对不同的听众，用不同的抽象来交流解决方案；
2. 摘抄
这本书主要覆盖的内容：
- 软件架构的本质；
- 为什么软件架构角色应当包含编码、指导、合作；
- 开始编码前真正需要思考的事情；
- 如何用简单的草图让你的软件架构可视化；
- 为软件生成文档的轻量方法
- 为什么敏捷和架构并不冲突；
- “恰如其分”的预先设计是什么意思；
- 如何通过风险风暴来识别风险；
关于架构的5件事
- 软件架构不是大型预先设计
- 每个软件团队都需要考虑软件架构
- 软件架构的角色关乎编码、指导和合作；
- 无需使用 UML；
- 好的软件架构是支持敏捷开发的；
想在这个行业里有所作为，就需要克制对新鲜玩意都迷恋，开始问一些问题。
很多架构师远离细节的主要原因之一是他们没有时间。
如果你了解如何编程，往往会忍不住对开发者如何编写代码提出建议。
不过，如果你没有参与项目的编程，开发者多半会无视你的编码经验。
软件架构师面临的问题
- 和其它可选技术相比，合适吗？
- 该系统的设计和构建，还有哪些选择？
- 是否应该采用一种通用的架构模式？
- 我们是否明白所做决策的利弊？
- 我们照顾到了品质属性的需求吗？
- 我们如何证明这种架构行之有效？
最优秀的软件设计师都有软件开发背景，
但并不意味着他们是团队中最好的程序员，
但他们能够在底层细节和大局之间切换。
结对编程有好处，那为什么不结对架构？
支撑软件架构角色的技术知识需要深度与广度并存的知识组合。
每个人都有自己的想法和计划，你在处理时得让他们不反感，并主动地去追求你需要的结果。好的影响力也要求好的倾听和探索能力。
辅导是对人进行学习方面的指引，
而非告诉他们怎么做一件事。
每个组织都少不了政治，我们离得越远越好。
但你至少应该明白周围发生了什么，
这样才能做出更可靠的决策。
责任感：你不能因为失败就责备软件开发团队中的其它人，有责任感对你而言很重要。
授权：在适当的时候授权，但记住，授权的可不是责任。
保持积极，构建正能量回路。
你的热情带动了团队，他们的热情也带动了你
软技能有时候比过硬的技术更重要，
交付产品的团队才是愉快的，
让团队保持积极是你的责任，
你的角色在整个团队中不应该低估。
软件架构要引入控制吗？
可以的，类似操纵杆，不是非黑即白，较自由
先从部分控制开始，倾听反馈，再微调。
我们正在失去技术导师
在我们的行业里许多开发者为了在企业晋升机制中有所发展，被迫转向非技术的管理岗位。
讽刺的是，被迫离开技术岗位的往往是最优秀和最资深的技术人员，而软件团队中则失去了最有价值的技术领导、架构师和导师。
很多团队连一个对“大局”之类的东西有经验的人都没有，一团乱麻的代码库、不明确的设计、很慢的系统，类似这些都是证明。
任何时候，在高层次上理解需求、约束和原则都至关重要。因为这是设计选型所需的基本知识。
软件架构谈论的是重要的设计决策，其重要性以变动的成本来衡量。
随说：ETC 原则 来自《程序员修炼之道：通向务实的最高境界》
用层来组织代码库使得软件整体结构更易于观察，但不容易改变特性或用户故事，你需要深入多个层(包、命名空间等)探究。
随说：组件更容易改变，聚合的。
因为架构和代码之间相互的映射往往非常少，我们要通过组件封装(闭环/类似微服务)对齐软件架构和代码，放弃使用层或特性。
只有 10%～20% 的听众在日常工作中经常使用 UML。
其实我们很多时候一张白纸、白板或者便利贴就够了，特别是一组人想通过协作来完成设计。
(三四个人挤在笔记本屏幕前有点奇怪，不能是投影？)其实最后还是要迁移到电脑系统上。
画图最好要加上图例，不是所有人都懂 UML。
软件架构流程就是为软件项目引入结构和愿景
- 从对个抽象层次看到并理解方案
- 理解大局，谁使用系统，IT环境依赖
- 逻辑容器和高层次技术选择(web服务器、DB)
- 有哪些主要组件，如何使用他们来满足用户故事、用例、功能，等等。
- 体现组件职责是什么、组件的归属
- 理解图表表示法、约定、颜色编码
- 图表之间的可追踪性
- 业务领域是什么，高层次视角看
- 理解实现策略(框架、类库、API)
代码不会讲完整的故事，我们需要文档辅助。
比如技术选型，一些决策过程，业务背景等
代码库 vs 旅游景点必看指南
随说：妙啊
旅游指南有实用信息：货币 电力 移民 法律…
源代码里面也应该包括实用信息：哪里找到源码、如何构建、如何部署、团队遵循的原则等等。
项目应该有文档去讲述产品如何工作、如何演化。
每个系统都应该有一份软件指南。
告知产品如何工作、演化的信息。
方面人们熟悉系统、优化系统。
软件指南包含：
语境
功能性概览
质量属性
约束
原则
软件架构
外部接口
代码
数据
基础设施架构
部署
运营和支持
决策日志
所有的决策都是依据特定的语境做出的，
通常都有取舍。
项目级文档 vs 产品级文档
思考软件架构的过程其实是确定范围，
在范围之内可以用任何一种 xDD 来实现。
架构代表了重大决策，衡量重要性的则是改变的成本。
3. 架构微博
- 《架构之道》
- 《架构师的12项修炼》
- 《软件架构：架构模式、特征及实践指南》
- 《微服务架构设计模式》
- 《凤凰架构》
- 《架构之美》
- 《架构修炼之道》
- 《高可用可伸缩微服务架构》
- 《高可用架构》
- 《可伸缩服务架构：框架与中间件》
- 《可伸缩架构》
- 《大型网站技术架构》
- 《架构真经》