[读书笔记] 代码整洁之道（四）

继续整理本书的内容。

第八章 边界

---

本章主要讲了如何控制代码的边界，己方代码与第三方代码之间，不同模块之间，核心的思想是，要保证边界整洁，需要透彻的浏览和学习边界，对边界内容进行过载的测试也是值得的，同时，对于尚未完成的依赖边界，要大胆的预使用它们，这样可以保证即便依赖之物尚未存在，仍不会耽误什么，同时，一旦依赖准备就绪，只需要少量的适配工作就可以很快的投入联调之中，Google的mock测试框架就是基于这样一种思想。
总之，边界上最常发生的事情就是改动，所以要尽可能的减少对于边界的依赖和假设，边界上的代码需要清晰的分割和定义了期望的测试，这样就能保证隔离或者封装边界的变化。

第九章 单元测试

---

本章说明了测试在软件开发过程中的重要地位，特别实在测试驱动开发（TDD）的模式当中，测试应该是整洁的，具有极好的可读性的代码，而不应该被当作“二等公民”，这个在实际项目中很难得，很多项目由于工期的原因，测试代码完全是为了达到某些指标服务的，跟低劣的注释半斤八两，完全失去了单元测试应有的意义，Hail， 单元测试。
补充一点关于单元测试的内容，之前总是把单元测试和单体测试混淆到一起，认为单元测是就是跑一边生产代码，看看有没有bug。其实不是这样子的，单元测试不是为了测试软件的各项功能，而是保证代码中的每一个函数（100%覆盖）在我们能想到的所有case中，都可以按照我们预期的结果运行，它是一种纯粹的代码角度的测试，跟代码功能没有直接的联系。引用一段轮子哥(vczh)的解析：

代码是为了什么，当然是为了重复运行。如何保持unit test代码的稳定？主要靠好的API设计。API切实正确切割了需求，那么在重构的时候API就基本不用变化，unit test也不用重写。以后你重构的时候，只要你的unit test覆盖的够好，基本跑一遍就知道有没有改成傻逼。可以节省大量的时间。
所以那些专门写不需要维护的软件的人，讨厌测试，也是情有可原的。

第十章 类

---

类面向对象的直接产物，继承，封装，多态，哪一个离了类也玩不转，所以设计良好的类在整个代码中的第五举足轻重。
从代码整洁的角度对类提出要求，那么最为重要的一个：类应该是短小的。
1. 从职责上来衡量，也就是要职责单一：只有一个修改它的理由。重构一书中说的很明白：如果A和B两个不同的需求都要改动C类，那么C类就是多职责的。从空间上来看，职责越少的类往往代码也不会太多，暴露给外界的接口数量也会在一个合理的范围之内，例如，一个包含上百个函数的类，我们没办法用“小”来衡量他们吧。
2. 从内聚性上来说，类应该是高内聚的，一种比较直观的衡量方法就是看类中每个函数使用的成员变量数量占所有成员变量的平均百分比，百分比越高，往往类的内聚性越好（相对而言，并不是说一定要追求100%，物极必反 :(|）。例如，类有10个成员变量，有6个成员函数，每个函数平均使用8个成员变量，那么使用的百分比就是80%，这意味着，类中的方法和变量相互依赖，互成一个逻辑整体。如果类中变量的使用情况呈现多极分化，也就是某几个变量集中在几个函数中，例如变量A，B，C集中在方法FA，FB，FC中，C，D，E集中在方法FC，FD，FE中，等等。那么该类多半可以拆分成几个小类。得到许多短小的类往往是保持类的高内聚的一个结果。