开卷有益：架构整洁之道

也未曾想过，重读此书。估计闲了，做下笔记，或感慨。这些年，我也做过一些项目，看起来，真的很糟糕，不是急匆匆上线，就是频繁调整需求。忽略了项目的设计，虽然环境是急躁的，但更多的是自己对项目，对自己的代码不负责的一种表现可能是。遇到实现比较麻烦的部分，往往也是如同书中所说那样，先实现后优化，但到了后面，优化起来，费时费力。而且新需求源源不断，也就得过且过。说是敏捷快发，但，从某种维度上来说，效果挺垃圾，估计是对敏捷的误解吧。程序员的代码，不仅要能正常运行，还需要适应需求的变化，如果无法适应，就会被淘汰。
作为程序员，Bob 大叔的这本著作，应该列为必读。强烈推荐。

架构即设计

开篇，就提出了 架构即设计 的理念，细想，似乎区别不大，对项目进行架构，主要是进行技术选型之类的，过于浅显，显然是种错读。而设计就比较明确，对系统底层组织结构和实现细节的把控。架构就像是设计的雅语而已，但，实际上，架构难道不需要了解系统底层组织结构和实现细节？
大叔提到了软件架构的终极目标是，用最小的人力成本来满足构建和维护该系统的需求，我是没有半点疑惑的，关于这种说法。如果不能降低构建和维护系统的成本，还那么费劲心思架构搞什么呢？如果一个好的设计，可以降低 50% 的成本，你觉得老板会怎么做。
系统可以从两个维度体现实际价值：

行为价值，让机器按照某种指定方式运转，给系统的使用者创造或者提高利润；
架构价值，系统的灵活性，变更实施的难度应该和变更的范畴成等比关系，而与变更的具体形状无关。

如果忽视软件架构的价值，系统将会变得越来越难以维护，终会有一天，系统将会变得再也无法修改。如果系统变成了这个样子，那么说明软件开发团队没有和需求方做足够的抗争，没有完成自己应尽的职责

编程范式

编程范式，主要是指程序的编写模式，与具体的编程语言关系相对较小。

结构化编程，对程序控制权的直接转移进行了限制和规范；
面向对象编程，对程序控制权的间接转移进行了限制和规范；
- 依赖反转，源代码依赖关系和控制流是相反的。
函数式编程，对程序中的赋值进行了限制和规范。

SOLID原则

SOLID原则主要是指导如何将数据和函数组织成为类，以及如何将这些类链接起来成为程序。

SRP，单一职责原则，一个软件系统的最佳结构高度依赖于开发这个系统的组织的内部结构。每个软件模块都有且只有一个需要被改变的理由；
OCP，开闭原则，如果软件系统想要更容易被改变，那么其设计就必须允许新增代码来修改系统行为，而非只能靠修改原来的代码；
LSP，里氏替换原则，如果想用可替换的组件来构建软件系统，那么这些组件就必须遵守同一个约定，以便让这些组件可以相互替换；
ISP，接口隔离原则，在设计中避免不必要的依赖；
DIP，依赖反转原则，高层策略性的代码不应该依赖实现底层细节的代码，恰恰相反，那些实现底层细节的代码应该依赖高层策略性的代码。

组件构建原则

组件是软件的部署单元，是整个软件系统在部署过程中可以独立完成部署的最小实体。

REP，复用/发布等同原则（黏合性），软件复用的最小粒度应等同于其发布的最小粒度；
CCP，共同闭包原则（黏合性），将由于相同原因而修改，并且需要同时修改的东西放在一起。将由于不同原因而修改，并且不同时修改的东西分开；
CRP，共同复用原则（排除性），不要强迫一个组件的用户依赖他们不需要的东西。