结构整洁之道(读书笔记)

第一章 设计与架构究竟是什么

设计与架构没有区别
架构图包含底层设计细节，细节支撑了顶层的架构设计

架构：用最小的人力成本来满足构建和维护系统需求
结构设计需要综合考虑编码、质量、部署、发布、运维、排障、升级等各种因素

过度自信只会使重构设计陷入和原项目一样的困局中

第二章 两个价值维度

1. 行为价值：完成需求，第一价值维度
2. 架构价值：软件的灵活性，第二价值维度，降低以后变更成本。好的系统架构设计应该尽可能左到与“形状”无关

艾森豪威尔矩阵：紧急/重要矩阵

第三章 编程范式总览

编程范式：

1. 结构化编程：对程序控制权的直接转移进行了限制和规划
2. 面向对象编程：对程序控制权的间接转移进行了限制和规范
3. 函数式编程：对程序的赋值进行了限制和规范
   编程范式的实际含义：从某一个方面限制和规范了程序员的能力，而不是增加新能力。主要告诉我们不能做什么，而不是可以做什么
   三个范式分别限制了 goto语句、函数指针、赋值语句的使用

编程范式和软件架构的关系：多态是跨越架构边界的手段，函数式编程是规范和限制数据存放位置与访问权限的手段，结构化编程是各模块的算法实现基础。
软件架构三大关注重点：功能性、组件独立性、数据管理

第四章 结构化编程

采用数学推导方法证明了：可以用顺序结构、分支结构、循环结构这三种结构构造出任何程序

大型问题——》一系列高级函数——》一系列低级函数——》结构化编程范式实现

如何证明小函数的正确性
每个函数都用欧几里得去证明正确性太过复杂，数学推导证明并不是证明结构化变成正确性的唯一手段，更合适的方法式：科学证明法

理论：
科学方法论不需要证明某条结论是正确的，只需要证明它是错误的，如果某个结论经过一定的努力无法证伪，我们则认为它在当下是足够正确的。
数学是要将可证明的结论证明，科学是要将可证明的结论证伪。

测试只能展示Bug的存在，并不能证明不存在Bug

上面理论说明了个问题：为什么结构化编程不支持goto
因为结构化编程促使我们将程序递归降解为一系列可证明的小函数
然后编写相关的测试来试图证明这些函数是错误的。
如果这些测试无法证伪，那么我们认为这些函数足够正确。
从而推导整个程序是正确的
但是如果程序采用了不加限制的goto，那么无论写多少测试用例都不足够证明其正确性！

第五章 面向对象编程

面向对象编程是以多态为手段来对源代码中的依赖关系进行控制的能力，这种能力让软件将架构师可以构建出某种插件式架构，让高层策略性组件和底层实现性组件相分离，底层组件可以被编译成插件，实现独立于高层组件的开发和部署。

第六章 函数式编程

将程序划分为可变和不可变两种组件。
不可变组件用纯函数的方式来执行任务，期间不更改任何状态。
不可变组件通过与可变组件通信来修改变量状态

未完待续······