第八章 边界
有时候我们在使用第三方程序包或者开源代码的时候，或者依靠公司其他团队的代码，我们都得干净利落的的整合进自己的代码中。这一章就是介绍保持保持软件边界整洁的实践手段和技巧。
1.对第三方进行学习性测试，当第三方程序包发布了新的版本，我们可以允许学习性测试，看看程序包的行为有没有发生改变。
2.使用尚不存在的代码，有时候我们的第三方，还没有开发好API，但又不能影响到我们的开发进度，所以我们先可以定义好自己想要的接口。如果第三方ok了，我们再对接起来。
3.通过接口管理第三方边界，可以使用ADApter模式将我的接口转换为第三方提供的接口。这个是要注意，第三方的代码和自己的代码混合太多，这样不便管理。
第九章 单元测试
敏捷和TDD运动鼓舞了许多程序员编写自动化单元测试，单元测试是确保代码中的每个犄角旮旯都如我们所愿的工作。
TDD三定律
- 除非这能让失败的单元测试通过，否则不允许去编写任何的生产代码。
- 只允许编写刚好能够导致失败的单元测试。 （编译失败也属于一种失败）
- 只允许编写刚好能够导致一个失败的单元测试通过的产品代码。
PS:什么是生产代码，这里有点迷惑。
测试代码和生产代码一样重要，它可不是二等公民，它需要被思考、被设计和北照料。它该像生产代码一样保持整洁。单元测试让你的代码可扩展，可维护，可复用。原因很简单，有了测试，你就不担心对代码的修改，没有单元测试，每次修改可能带来缺陷，一个测试，一个断言。一个测试，对应一个概念。我们不想要超长的测试函数。
测试还应遵守以下5条规则。
1.快速 测试应该能快速运行，太慢了你就不会频繁的运行，就不会尽早的发现问题。
2.独立。测试应该相互独立，某个测试不应该为下个测试设定条件。当测试相互依赖，一个没通过导致一连串的测试失败，使问题诊断变的困难。
3.可重复。测试应该可以在任何环境中重复通过。
4.自足验证 测试应该有布尔值输出，无论通过或失败，不应该是查看日志文件去确认
5.及时。单元测试应该恰好在使其通过的生产代码之前编写。
第十章 类
1.类应该短小
2.单一权责原则(SRP)：类或模块应有且只有一条加以修改的理由。系统应该有许多短小的类而不是巨大的类组成。
PS：每个达到一定规模的系统都会包括大量逻辑和复杂性。管理这种复杂性的首要目标就是加以组织，以便开发者在哪儿能找到东西，反之，拥有巨大、多目的的类的系统，总是让我们在目前并不需要了解的一大堆东西中艰难的跋涉。
3.内聚：如果一个类中的每个变量都被每个方法所使用，则该类具有最大的内聚性。内聚性高，意味着类中的方法和变量相互依赖，相互结合成一个逻辑整体。
4.为了修改而组织。开放闭合原则（OCP）：类应当对扩展开放，对修改封闭。我们可以借助接口和抽象类来隔离这些细节带来的影响。
借鉴于https://www.cnblogs.com/stoneniqiu/p/4815259.html
之前的做法 之前设计的方法并不好 没有思考全面
现在的做法 学会义务上下范围图 对边界有了一点的了解 加强对类封装和使用