1.可测代码的好处
- 方便编写单元测试,保证代码质量
- 代码复用性较高
- 模块耦合性较低
- 容易测试的代码往往结构合理,分工更明确
- 代码可读性强
- 代码的可维护性好
2.提高可测性方法
- 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!”。(低耦合)
- 这些设计原则以及原则的实现方法有一些工共同点
- 低耦合。降低模块或者对象之间耦合度。模块可测性提高、复用性增强、分工明确、结构合理
- 高内聚。提高模块或者对象内部功能内聚性。代码职责更专一、核心功能更突出、可维护性和可读性增强
- 干净的构造函数
- 出现new关键字
- 有静态函数调用或者属性在声明的时候直接调用静态函数初始化
- 程序中使用初始化块
- 构造函数执行完之后并没有彻底完成对象初始化工作
- 对外部提供可见的初始化函数 (如:initXXX)
- 构造函数中出现控制逻辑(比如if/else、for等关键字)
- 编写轻量级API
- 接口笨重的表现
- API传参封装过度,接口变得笨重
- 使用超过一层.号调用
- 参数中出现context, environment, principal, container, manager的变量
- 编写轻量级API遵循法则
- 按需传参(不传入多余的参数)
- 接口实现保持简单的引用关系
- 接口笨重的表现
- 谨慎使用全局变量和单例模式
单例模式一种常用经典的设计模式。我们在享受单例模式带来的好处的 同时并常常忽略了它也给我们的代码带来诸多 隐患。
- 优点:在任何一个地方都可以方便的获取全局信息,使用方便。单例模式的使用在业界也有很多争议,很多时候可 以通过传参的方式实现单例的效果。
- 缺点:对外屏蔽了变量的使用,在没有授权的情况下可以随时随地的 被他人 修改状态 . 程序并发的正确性由开发 者来保证,使用时候要足够小心 . 只能生成一个对象实例,并行测试困难 (正常逻辑一样可能有并发性 能问题) . 单 例模式使得单例中的所有非全局变量也成为全局变量。
全局资源被共享,并发编程需小心。全局资源增加了增加程序并发风险。确认下是否真的有必要使用这些代码,能用
局部尽量不用全局。有如下代码要引起注意:
a. 单例模式
b. static变量或者method
c. static initial block
编写可测性代码最初目的是方便代码的测试,提高代码质量。
代码的可测试性带来的好处除此之外还有很多,这个已经
在第一章节探讨过。编写测试用例就是在使
用代码,可测性提高自然提高了代码易用性
。