# 《架构整洁之道》读书笔记 1
# 架构的目标
用最少的人力成本满足构建和维护该系统的需求
衡量标准可体现在（工程师团队，规模代码，总行数代码变更行数）
# 软件系统的价值
工程开发中要将重要且紧急和不重要但紧急的业务任务分开，并将重要但不紧急的架构任务插入其中
# 行为价值
行为价值是软件的核心价值，包括需求的实现，以及可用性保障（功能性 bug 、性能、稳定性）
架构的价值就是让我们的软件（Software）更软（Soft）
# 架构价值
- 当需求变更时，所需的软件变更必须简单方便。
- 变更实施的难度应该和变更的范畴（scope）成等比，而与变更的具体形状（shape）无关。
# 编程范式
编程范式的核心目的是：设置限制，告诉我们不可以做什么
# 结构化编程
目的：对控制权的直接转移进行了限制和规范
内容：可以用顺序接口、分支结构、循环结构这三种结构造出任何结构，并限制goto语句的使用
意义：用代码把一些已证明的结构串联起来，就可以推导出整个程序的正确性。实际上没有办法证明每个程序段是正确的只能证伪，如果所有的基本单原都无法证伪，那么整个就是无法证伪的，那目前就是正确的。
延伸：物理学与数学的区别，物理学的基本公式都是没有办法证明的，只能证伪，所以物理是实验科学，没有一个方式是完全靠得住的，只是目前靠得住。数据的基本公式是可以证明的
# 面向对象编程
目的：对程序控制权的间接转移进行了限制和规范
面向对象三大特性
- 封装：只暴露部分函数，数据则完全不暴露
- 继承：与架构并无大关系（忽略不计）
- 多态：其实只是函数指针的一种应用，通过接口和实现抽象类和继承，替代了函数指针的使用
意义：函数指针，是跨越组件边界的方法，是组件独立部署的基础，依赖反转的基础。依赖反转指的是让依赖与控制流向相反
# 函数式编程
目的：对赋值进行了限制和规范
趋势：如果有足够大的存储量和计算量，应用程序可以用事件溯源的方式，用完全不可变的函数式编程，只通过事务记录，从头计算状态
意义：所有的竞争问题、死锁问题、并发问题都是由可变变量导致的。
应用：通过将状态修改的部分和不需要修改的部分分隔成单独的组件，提高系统的稳定性和效率
# 设计原则：SOLID
意义：如何将数据和函数组织成类，如何将类链接成组件和程序
# SRP ：单一职责原则
目标：指导类、组件拆分【拆分】
定义：任何一个软件模块，都应该有且只有一个被修改的原因，被修改的原因指系统的用户或所有者
痛点：
- 同样的一块逻辑，如果服务于两个价值主体:因为一个价值主体而修改，那么第二个价值主体期望的功能将被影响。比如 CTO 和 COO 都要员工的工时，分别用于计算薪资和汇报，两者的计算方式可能目前是相同的，一方有了更改，另一方就 bug了
- 如果一块代码，归属于两个团队共同维护，就会有代码合并问题
# OCP ：开闭原则
目标：让系统易于扩展，同时限制每次修改所影响的范围
实现：划分组件，并将组件间依赖关系按层次结构进行组织
本原则是我们进行架构设计的主导原则
# LSP ：里氏替换原则
目标：指导接口与实现方式【边界处理】
内容：
- 不是实现了同一个接口，它们的行为就一致并可以互相替换，长方形正方形是典型的案例
- 如果两个组件，替换之后需要分别做特别的设置，那就说明抽象的还不足够，会引入许多 if-else ，可以同配置清单等方式消除
# ISP ：接口隔离原则
目标：指导接口的定义【边界处理】
内容：
- 不依赖任何不需要的组件、类、方法
- 如果不同的用户分别使用一个大接口的几个不同的方法，那么应该把这个大接口拆分为针对这些用户的小接口
# DIP ：依赖反转原则
目标：指导依赖方向
内容：组建间跨越边界的源码依赖的方向永远与控制流的方向相反