解惑

解己之惑,解人之惑

日:2009年6月7日

使用Checklist提升项目的质量

Checklist这个词是我在做一个日本的外包项目时学到的,问题源于我们最初提交的代码质量非常的差,很多基本的内容编码人员都没有去处理,例如缩进,注释,日志处理,异常处理等,而且由于我们使用的是他们提供的框架,框架本身也有一些要求,到了后来,我们根据以前常见的问题罗列了一个list,而另外抽调了几个人专门根据这个列表进行检查,就演变为checklist,而且这个列表是不断更新的,发现新的共通的错误就加进去,如果有原来的检查项在经过一段时间后几乎就没有再出现过就从列表中删除以减少检查人员不必要的工作。最重要的是这个经验后来被推广到其它的项目组,以及项目的各个阶段,例如需求分析有需求分析的checklist,设计有设计的checklist,即使是测试组也有自己的checklist,因为有些刚刚开始做测试的人对于基本的测试原理并不熟悉,例如边界测试,极大值极小值测试,异常系测试,对于经常被新人忽略的的测试类似就会有一个这样的list,而且每个系统会有一些自己特有的需要特别关注或者以前比较容易出问题的地方,也可以列到这个list里面。这样在整个软件周期中我们可以避免很多常见的问题,大大提升软件的整体质量。

提升项目组的开发效率

通过几年的实际工作,也参与了规模不一的多个项目,但是项目组的开发效率一直不高,一直都在思考这个问题的症结,最近换了一个公司,由于刚刚去,也不能修改比较核心的代码,就给他们修改bug,在修改其中一个比较有共性的问题时接触了很多他们原来写的代码,发现代码中充斥着很多完全相同或者几乎完全相同的代码,最典型的就是获得数据库连接以及关闭数据库连接的代码,有的类会封装一个自己用的方法,有的就是干脆每次重复,有的更是有相关的方法但是代码的其它地方却没有用,这个现象给了我比较大的触动,现在仔细想想,其实影响一个项目组的开发效率的很大的因素就是代码共享和知识共享太缺乏了。但是代码共享和知识共享又确实是比较困难的事情,共通的功能如何使用,需要什么约束条件,能够完成什么功能等等都需要有比较完善的文档,而一旦这样的功能多起来以后你要从这些功能中找到需要的功能有时候确实是比较困难的,特别是有些功能去查是否有现成的代码所花费的时间可能比自己写一个还多。

根据我的经验,有几个地方注意一下就可以比较好的解决: 
 
共通的内容要易于使用和理解,例如定义的方法名要比较贴切。 
要写比较详细的说明文档,例如给大家发邮件或者发布到内部使用的论坛系统中。 
在公布之前经过充分的测试,否则使用的时候总是有各种问题会导致大家不敢再用共通的代码。 
对于类似的功能有其共通的代码,例如使用struts的系统有自己的系统的顶层的BaseAction,在这个BaseAction中定义系统中的子类需要实现的业务逻辑方法入口,而BaseAction要实现structs要求的execute方法,并完成所有的共通任务,例如是否登录的检查,session是否超时等 
业务功能要比较少的关心杂项共通功能,例如定义logger,获取数据库连接,关闭数据库连接,异常处理等,这些功能都可以定义在BaseAction或者是系统的顶层基类中。 
  而且通过使用共通功能也可以很大程度提高系统的质量,因为通过这些年的实践发现,很多新人由于开始不理解系统的要求,很多地方就是先抄袭别人甚至完全拷贝别人的代码,如果别人的代码是有问题的,那么在没有出问题之前是很难被自己发现的,而到了发现的时候已经积重难返了,而通过顶层类的封装,底层的类的空间就狭窄了,犯错误的可能性就小多了,因为很多系统的共通要求在顶层类中已经实现了。

© 2025 解惑

本主题由Anders Noren提供向上 ↑