2022年四月第18本书
阅读速度4000字/分钟
1、本书主题：软件架构设计入门
2、速读建议：先看每章末尾小结，再阅读开头。
>> 程序员可以分为三个层次：普通程序员、工程师和架构师。
>> 工程师不仅仅是在编写代码，他们会用工程的方法来编写代码，以便让编程开发更为高效和快速。
>> 所谓架构就是“用最小的人力成本来满足构建和维护系统需求”的设计行为。
◆ 前言
>> 自1964年，12岁的我写下了人生的第一行代码算起，到2016年，我已经编程超过50年。
>> 如果深入研究计算机编程的本质，我们就会发现这50年来，计算机编程基本没有什么大的变化。编程语言稍微进步了一点，工具的质量大大提升了，但是计算机程序的基本构造没有什么变化。
>> 虽然我们有了新的编程语言、新的编程框架、新的编程范式，但是软件架构的规则仍然和1946年阿兰·图灵写下第一行机器代码的时候一样。
>> 写这本书就是为了讲述这些规则，这些永恒的、不变的软件架构规则。
◆ 第1章 设计与架构究竟是什么
>> 所谓的底层和高层本身就是一系列决策组成的连续体，并没有清晰的分界线。
>> 要想跑得快，先要跑得稳。
>> 本书为读者描述了什么是优秀的、整洁的软件架构与设计，读者可以参考这些设计来构建一个长期稳定的、持久优秀的系统。
◆ 第2章 两个价值维度
>> 软件系统的行为是其最直观的价值维度。
>> 软件系统的第二个价值维度，就体现在软件这个英文单词上：software。“ware”的意思是“产品”，而“soft”的意思，不言而喻，是指软件的灵活性。
>> 紧急的事情常常没那么重要，而重要的事情则似乎永远也排不上优先级。
>> 四类事情进行如下排序：1．重要且紧急2．重要不紧急3．不重要但紧急4．不重要且不紧急
◆ 第3章 编程范式总览
>> 三个编程范式，它们分别是结构化编程（structuredprogramming）、面向对象编程（object-oriented programming）以及函数式编程（functional programming）。
>> 结构化编程对程序控制权的直接转移进行了限制和规范。
>> 面向对象编程对程序控制权的间接转移进行了限制和规范。
>> 函数式编程对程序中的赋值进行了限制和规范。
◆ 第4章 结构化编程
>> 科学和数学在证明方法上有着根本性的不同，科学理论和科学定律通常是无法被证明的，譬如我们并没有办法证明牛顿第二运动定律F=ma或者万有引力定律F=Gm1m2/r2是正确的，但我们可以用实际案例来演示这些定律的正确性，并通过高精度测量来证明当相关精度达到小数点后多少位时，被测量对象仍然一直满足这个定律。
>> 科学理论和科学定律的特点：它们可以被证伪，但是没有办法被证明。
>> 科学方法论不需要证明某条结论是正确的，只需要想办法证明它是错误的。如果某个结论经过一定的努力无法证伪，我们则认为它在当下是足够正确的。
◆ 第5章 面向对象编程
>> 面向对象编程就是以多态为手段来对源代码中的依赖关系进行控制的能力，这种能力让软件架构师可以构建出某种插件式架构，让高层策略性组件与底层实现性组件相分离，底层组件可以被编译成插件，实现独立于高层组件的开发和部署。
◆ 第6章 函数式编程
>> 一个架构设计良好的应用程序应该将状态修改的部分和不需要修改状态的部分隔离成单独的组件，然后用合适的机制来保护可变量。
◆ 第7章 SRP：单一职责原则
>> 每个模块都应该只做一件事。
◆ 第10章 ISP：接口隔离原则
>> 任何层次的软件设计如果依赖了它并不需要的东西，就会带来意料之外的麻烦。
◆ 第11章 DIP：依赖反转原则
>> 如果想要设计一个灵活的系统，在源代码层次的依赖关系中就应该多引用抽象类型，而非具体实现。
◆ 第12章 组件
>> 程序的规模会一直不断地增长下去，直到将有限的编译和链接时间填满为止。
◆ 第13章 组件聚合
>> 软件复用的最小粒度应等同于其发布的最小粒度。
>> 将由于相同原因而修改，并且需要同时修改的东西放在一起。将由于不同原因而修改，并且不同时修改的东西分开。
>> 不要依赖不需要用到的东西。
◆ 第14章 组件耦合
>> 依赖关系必须要指向更稳定的方向。
>> 一个组件的抽象化程度应该与其稳定性保持一致。
>> Nc：组件中类的数量。Na：组件中抽象类和接口的数量。A：抽象程度，A=Na÷Nc。A指标的取值范围是从0到1，值为0代表组件中没有任何抽象类，值为1就意味着组件中只有抽象类。
>> 摩尔定律：计算机的处理速度、内存、存储密度每18个月会增长1倍。这条定律从1950年到2000年一直适用，之后在处理速度方面就停滞不前了。
◆ 第5部分 软件架构
>> 设备无关性的价值真是太巨大了！它使我们的程序不再需要关心具体使用的I/O设备。
>> 优秀的架构师会小心地将软件的高层策略与其底层实现隔离开，让高层策略与实现细节脱钩，使其策略部分完全不需要关心底层细节，当然也不会对这些细节有任何形式的依赖。另外，优秀的架构师所设计的策略应该允许系统尽可能地推迟与实现细节相关的决策，越晚做决策越好。
◆ 第16章 独立性
>> 康威定律：任何一个组织在设计系统时，往往都会复制出一个与该组织内沟通结构相同的系统。
◆ 第17章 划分边界
>> 简单来说，通过划清边界，我们可以推迟和延后一些细节性的决策，这最终会为我们节省大量的时间、避免大量的问题。这就是一个设计良好的架构所应该带来的助益。
◆ 第18章 边界剖析
>> 系统架构中最强的边界形式就是服务。一个服务就是一个进程，它们通常由命令行环境或其他等价的系统调用来产生。
◆ 第19章 策略与层次
>> 本质上，所有的软件系统都是一组策略语句的集合。是的，可以说计算机程序不过就是一组仔细描述如何将输入转化为输出的策略语句的集合。
◆ 第20章 业务逻辑
>> 严格地讲，业务逻辑就是程序中那些真正用于赚钱或省钱的业务逻辑与过程。
>> 业务逻辑应该是系统中最独立、复用性最高的代码。
◆ 第21章 尖叫的软件架构
>> 假设我们阅读的是一幅图书馆的建筑设计图，情况也差不多。我们应该会先看到一个超大入口，然后是一个用于签到/签出的办公区，接下来是阅读区、小型会议室，以及一排排的书架区。同样，几乎整个建筑设计都在尖叫着跟你说：这是一个“图书馆”。
◆ 第22章 整洁架构
>> 源码中的依赖关系必须只指向同心圆的内层，即由低层机制指向高层策略。
◆ 第26章 Main组件
>> 在所有的系统中，都至少要有一个组件来负责创建、协调、监督其他组件的运转。我们将其称为Main组件。
>> Main组件是系统中最细节化的部分——也就是底层的策略，它是整个系统的初始点。
◆ 第29章 整洁的嵌入式架构
>> “虽然软件本身并不会随时间推移而磨损，但硬件及其固件却会随时间推移而过时，随即也需要对软件做相应改动。”
>> 1.“先让代码工作起来”——如果代码不能工作，就不能产生价值。2.“然后再试图将它变好”——通过对代码进行重构，让我们自己和其他人更好地理解代码，并能按照需求不断地修改代码。3.“最后再试着让它运行得更快”——按照性能提升的“需求”来重构代码。
◆ 第6部分 实现细节
>> 数据库只是一款软件，是用来存取数据的工具。从系统架构的角度来看，工具通常是无关紧要的——因为这只是一个底层的实现细节，一种达成目标的手段。一个优秀的架构师是不会让实现细节污染整个系统架构的。
◆ 第31章 Web是实现细节
>> GUI只是一个实现细节。而Web则是GUI的一种，所以也是一个实现细节。
