笔记6、边界(引用库或他人代码)
优雅的使用第三方库
大多数人是通过花好几天阅读文档，再决定怎么使用，然后编写。最后不免陷入漫长的调试找代码中的缺陷中。因为学习第三方库代码很难，整合第三方代码也很难。
优雅的使用第三方库，则应该换一种方法。
优雅的方式:编写学习性测试。
找到最基础的文档(用来给第一次使用的人看的)，开始阅读文档。每读完几个的api，便开始整合完成你想要的某一个功能，写一个类的一个函数将其封装起来。
完成你初步罗列出来的功能便可以开始测试，如果不需要深入理解他人的代码的话，完成所需功能即可。如果想要开发超过百行的有关代码，还是把最基础文档的api全部测试一遍好。
测试:对函数分别调用，从中弄懂参数和返回值的真正意义，并以此弄清当前函数整合的所有api干了什么。
测试完成后，便应该只用自己封装起来的函数来写自己旳程序。当需要调用新的api，如果这个api属于之前的某个功能，就写进那个功能对应的函数，如果是新的功能，则应该考虑写新的类、新的的函数。
编写学习性测试的好处
减少了学习成本，减少了混乱的调试，比以前的方法更有效。
当他人的代码更新了后，api作用可能会改变，这时候可能会产生兼容性问题，造成你的程序大范围的出错，而且不易于定位错误，修改代码的代价巨大。而通过编写学习性测试，我们只需将之前编写的函数重新测试一遍，再把出错的函数修改即可。
当我们需要的代码还未存在的时候，我们可以编写类似于学习测试的代码，原理仍是通过所需功能来编写函数，这叫做adapter模式。我们通过这种模式，将所需功能写出，因为这样一切我们程序所需调用的函数接在我们的掌控之中，而不是他人的改动的代码。这就类似于一个过渡层，通过它，我们将不同人编写的代码融合。
7、类
类的组织
1、类应该从一组变量列表开始。如果有公共静态常量，应该先出现。然后是私有静态变量，以及私有实体变量。很少会有公共变量（尽量可能公共变量的数量）。
2、公共函数应跟在变量列表之后，最后再是私有函数。
类应该短小
1、类名应该精确。类的名称应该描述其全责。
2、一个类应该只有一个全责。
3、内聚。类应该只有少量实体变量。类中的每个方法都应该操作一个或多个这样的变量。高的内聚性，意味着类中的方法和变量互相依赖、互相结合成一个逻辑整体。
4、有时候，随着对方法的扩充，实体变量的数量开始上升，往往这意味着至少有一个类要从大类里面挣扎出来。重构代码后，实体变量就分给几个不同的类了。
修进类的技巧
我们知道编写一个类不是一触而就的，而是通过了无数次修进的。而系统的每处修改（添加功能，改变逻辑方法等）都让我们冒着系统会出现问题的风险。这时候我们要对类加以修进（组织和重构），以降低修改所面临的风险。
1、当一个类庞杂巨大需要重构的时候，将一个类分隔为几个类，用明确的功能权责来划分。
2、当有新特性要添加时，可以写一个新类，如果能达到新类只用了原有类的极少数（一个或两个）方法时，就是低耦合度。原有类没有被干扰，新类也相当简洁（只服务于某个新特性）。
8、单元测试
1、测试应与生产代码应在同一个时间段内编写，先写测试代码再写生产代码。每编玩一个新的功能，就应该写测试来检验功能的是否实现。每次更改生产代码，也应修改测试代码。
2、保持测试代码的整洁。不要以为只是测试就不写整洁的代码，脏测试等同于没测试。测试必须随生产代码的眼镜儿修改，测试代码越脏，就越难修改，修改生产代码后，测试就会开始失败，随着版本的演进，团队维护测试代码的代价也在上升，而随着开发的进行，开发压力的一直增大，最终会导致开发者扔掉整个测试站组。一旦没了测试代码，程序员就失去了确保对代码的改动能如愿工作的能力。这时候整个生产代码开始腐坏。
编写单元测试的技巧
每个测试一个断言。每个测试中的断言，要尽可能少！不能把不同的测试放在一起。
我们通过打造一套包装这些api的函数和工具代码，这样就可以更方便的编写测试，写出来的测试，也更便于阅读。我们通过测试那些函数和工具代码，从而测试那些api。
函数和工具代码也以功能为构建目标，不同的功能用不同的函数。
这种测试的函数和代码工具并非当初就设计出来，而是在对那些充满令人迷惑细节的测试代码进行后续重构时逐渐演进。
测试带来的好处
单元测试让你的代码可扩展，可维护，可复用。没有测试，每次修改都可能带来缺陷。
编写单元测试的模式
单元测试可以采取构造-操作-检验模式写成一个函数。也就是将测试拆分为三个环节，第一个环节构造测试数据，第二个环节操作测试数据的，三个环节，检验操作是否得到期望的结果。
测试代码与生产代码的不同
测试代码应当简单精悍足具表达力。有些事你大概永远不会在生产环境中做，而在测试环境中做却完全没问题。 通常这关乎内存和upu效率的问题(比方要求在多少秒内，内存不应该超过多少多少)。
这是代码应该极具阅读性。
整洁的测试遵循的规则
1、快速。测试不应该过于缓慢，如果测试过于缓慢，你就会不想频繁的测试，如果你不频繁运行测试，就不能尽早发现问题。代码将腐化。
2、独立。测试之间应该相互独立，一个功能一个功能的测试，不会相互依赖。
3、可重复。测试应当可在任何反应中重复通过。
4、自足验证。测试的结果应该明显，最好是bool值，不应通过查看日志这种低效率的方法来判断测试是否通过。应当由程序来判断。
5、及时。测试应该及时编写。单元测试，应该恰好在使其通过的生产代码之前编写。
