引言
近来开始阅读 Robert C. Martin 的新著《架构整洁之道》（Clean Architecture）。没有人愿意看到团队内的项目逐渐发展成一团乱麻，相互纠缠。那如何从根本上减少这种问题的发生呢？这就需要我们掌握一些宏观层面的设计思想，从给项目打基础时就应该考虑好各个模块、类、函数等如何设计成高内聚、低耦合的结构。整洁的项目架构是利于长远发展的，这篇笔记将会记录一些从书中学习到的重要知识点，便于后期复习和参考。
当然，作者还有一本大名鼎鼎的著作《代码整洁之道》也非常值得阅读，关于这本书也做了点笔记，参见《代码整洁之道》读书笔记~
要点记录
什么是设计和架构
- 计算机代码这么多年没有发生本质的变化，导致软件架构的规则保持了一致。软件架构的规则其实就是排列组合代码块的规则
- 让一个程序可以工作非常容易（小孩子都能做到），但让它正确地工作则是另外一回事。而让软件正确工作则更加困难，因为这需要开发人员有独到的思想和远见，掌握一定的设计规则
- 在软件设计中，底层的细节和上层的结构是一个整体，不可分割
- 软件架构的目标是最小化构建和维护系统所需要的人力资源
- 不要总是寄希望于以后来解决技术债务，因为你会发现以后总是很遥远
- 事实是 making messes is always slower than staying clean
- 走得快的唯一办法，是先走好（The only way to go fast, is to go well）
价值对比：表现 vs 结构（架构）(Behavior and Structure）
- 任何软件系统都会在两个方面产生价值：Behavior 和 Structure
- 表现（Behavior）：软件被开发用来让计算机按照预期的方式工作并产生价值，或者为人们解约开支
架构（Architecture）：
- 软件应该易于更变其行为表现（灵活、可扩展）
- 如果大部分需求变更只是局部变化，而不是影响到整体架构「外形（shape）」的话，那应该没什么难度，但如果架构本身无法满足需求实现，则会带来很大的开发成本
- 架构本身如果只局限于某种「外形（shape）」（或者更偏向于），那新增功能可能会越来越复杂。所以说，架构本身不要把自己限制死，应该是能灵活应对变化频繁的需求的。更为实际的架构应该是对「外形」无感知的（更强的包容性）
作为软件工程师，我们不能一味地满足产品经理们各种功能堆积，而忽略了软件质量，也同样要让软件架构变得更灵活
- Dwight D. Eisenhower: “I have two kinds of problems, the urgent and the important. The urgent are not important, and the important are never urgent”
我们可以根据重要性和紧急性对任务做如下分类：
- 紧急 + 重要（比如出现了影响用户的大 Bug）
- 不紧急 + 重要（架构、工程质量、代码重构）
- 紧急 + 不重要（需求通常比较紧急，但并不总是非常重要的）
- 不紧急 + 不重要
很多情况下，项目经理会误判优先级，把「紧急 + 不重要」的任务认为是优先级最高的，这样就导致开发人员忽略了软件架构，让系统变得越来越脆弱
- 开发人员的职责就是要确定架构和所谓的紧急需求哪个是真的更重要的
- 作为开发团队的一员，守护你的项目质量是你的职责所在；而作为架构师，更需要重点关注系统结构而非各种特性和功能，良好的架构应该允许各种特性和功能易于添加，修改和扩展
小结
正所谓「理想很丰满，现实很骨感」，现实开发中如果想要保证快速迭代的同时，尽可能不破坏项目结构，虽然有点困难，但并非做不到。首先项目本身在最初设计时就应该是为方便扩展考虑的（如模块化、编写风格等）；其次，团队的成员应该是要有较强的责任心来保护这种良好的设计，这样在扩展新功能时就会更加顺利。