注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

网易杭研后台技术中心的博客

 
 
 
 
 

日志

 
 

编写可测性代码  

来自yfkscu@126   2013-09-18 09:14:17|  分类: 开发技巧 |举报 |字号 订阅

  下载LOFTER 我的照片书  |
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

编写可测性代码最初目的是方便代码的测试,提高代码质量。代码的可测试性带来的好处除此之外还有很多,这个已经在第一章节探讨过。编写测试用例就是在使用代码,可测性提高自然提高了代码易用性。 
 
                评论这张
               
              阅读(961)| 评论(1)
              推荐 转载

              历史上的今天

              评论

              <#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
               
               
               
               
               
               
               
               
               
               
               
               
               
               

              页脚

              网易公司版权所有 ©1997-2017