编写可测性代码

1.可测代码的好处 

• 方便编写单元测试，保证代码质量 
• 代码复用性较高
• 模块耦合性较低 
• 容易测试的代码往往结构合理，分工更明确 
• 代码可读性强 
• 代码的可维护性好 

2.提高可测性方法

• TDD

TDD是一种测试先行的开发模式。简单的讲就是在编写代码之前先编写测试代码。

优点：测试先行很好的保证了代码的可测性 

缺点：耗时较多、打破了一般程序员的常规设计思路、实践起来较为困难 

• 为何TDD难以执行？ 
  • 开发时间太紧，很难做到任何代码测试先行 
  • 开发过程需求变动，测试用例失效需要重构，这样以来耗时更多 
  • 开发测试用例耗时，如何保证测试用例的正确性和合理性也是一个问题 
  • 打破了常规思维，拿到一个问题首先先到解决问题的方法，而不会先去
  • 思考再想一个方法来证明这个方法是否正确 
• 如何利用好TDD设计思路？
  • 代码最终可测，开发过程中不必过多考虑测试问题，不用按部就班的遵循传统意义上的TDD 
  • 可测试作为向导，写代码时为单元测试留下入口
  • 发现测试用例不易实现，此时需要反思代码是否合理，不断重构最终可测

• 可测性设计方法
  • Law of Demeter（迪米特法则）又叫作最少知道原则（Least Knowledge Principle 简写LKP），迪米特法则可以简单说成：talk only to your immediate friends。就是说一个对象应当对其他对象有尽可能少的了解。（耦合降低）
  • Single Responsibility Principle （单一职责法则），一个对象做的事情尽量单一，突出核心功能，且莫生成万能的对象（包揽各种功能）。因为专业所以卓越！（提高内聚） 
  • 可替换法则，尽量保持每个类容易被替换，常用办法有面向接口编程。（耦合降低） 
• 谈谈AOP、IOC思想

这两种思想其实和上面的三种原则有什么联系呢？ 

这两个模式也是Spring的设计设计模式精髓一部分。 

• AOP（Aspect Oriented Programming），面向切面编程。 让业务逻辑专心做核心的事情去吧！常见的又日志记录、资源的打开和关闭等应用....... （高内聚） 
•  IOC（inversion of control），控制反转或者依赖注入。 简单的说就是一个对象用到其他对象，不是在代码里面new而是直接通过构造函数、set函数或者其它方法注入。我的理解：需要谁就注入谁，而不是自己去找谁。也有的文章中称作“Don’t look for things! Ask for things!”。（低耦合）
• 这些设计原则以及原则的实现方法有一些工共同点
  • 低耦合。降低模块或者对象之间耦合度。模块可测性提高、复用性增强、分工明确、结构合理 
  • 高内聚。提高模块或者对象内部功能内聚性。代码职责更专一、核心功能更突出、可维护性和可读性增强

3. 如何编写可测性代码

• 干净的构造函数

原则上构造函数不应该做逻辑处理，只是用来初始化一些参数。若构造函数复杂，则使其变得笨重，不利于单元测试。因为要new这个对象需要使用者了解其实例化的细节。（违反Law of Demeter） 如果发现构造函数如下特征，应该引起注意，检查代码是否可以优化。

•  出现new关键字 
•  有静态函数调用或者属性在声明的时候直接调用静态函数初始化 
•  程序中使用初始化块 
•  构造函数执行完之后并没有彻底完成对象初始化工作 
•  对外部提供可见的初始化函数 （如：initXXX） 
•  构造函数中出现控制逻辑（比如if/else、for等关键字） 
• 编写轻量级API
  • 接口笨重的表现
    • API传参封装过度，接口变得笨重
    • 使用超过一层.号调用
    • 参数中出现context, environment, principal, container, manager的变量
  • 编写轻量级API遵循法则 
    • 按需传参（不传入多余的参数） 
    • 接口实现保持简单的引用关系 
• 谨慎使用全局变量和单例模式

单例模式一种常用经典的设计模式。我们在享受单例模式带来的好处的 同时并常常忽略了它也给我们的代码带来诸多隐患。

• 优点：在任何一个地方都可以方便的获取全局信息，使用方便。单例模式的使用在业界也有很多争议，很多时候可以通过传参的方式实现单例的效果。 
• 缺点：对外屏蔽了变量的使用，在没有授权的情况下可以随时随地的被他人 修改状态 . 程序并发的正确性由开发者来保证，使用时候要足够小心 . 只能生成一个对象实例，并行测试困难（正常逻辑一样可能有并发性 能问题） . 单例模式使得单例中的所有非全局变量也成为全局变量。

全局资源被共享，并发编程需小心。全局资源增加了增加程序并发风险。确认下是否真的有必要使用这些代码，能用局部尽量不用全局。有如下代码要引起注意： 

a. 单例模式 

b. static变量或者method 

c. static initial block

编写可测性代码最初目的是方便代码的测试，提高代码质量。代码的可测试性带来的好处除此之外还有很多，这个已经在第一章节探讨过。编写测试用例就是在使用代码，可测性提高自然提高了代码易用性。