论代码走查的重要性

  在一个团队中, 如果没有code review, 直接允许开发提交代码到版本库并部署环境, 那么在正式开始测试之前的代码走查就非常有必要了。

  这里说的走查不是使用工具在持续化集成之前进行代码规范的检查, 而是根据PRD文档, 验证代码的实现是否符合需求描述。

  在开始测试之前我都会先同步开发的代码, 然后询问开发人员具体有哪些接口涉及到本次功能提测, 之后从每个接口入手, 查看业务逻辑层与数据库访问层代码, 看其实现是否与需求相符, 并找出一些明显的错误。这样做的目的只有一个, 那就是节省时间。其实这些问题应该在开发提交代码前由code review发现的, 但是由于团队刚刚组建,没有形成一套合理的流程,而且时间非常有限。其实这些恶性bug都是可以在测试阶段发现的,而且是在冒烟测试阶段就能轻易发现,但是问题还是时间紧,不如先走查一遍代码,将错误处与开发沟通,之后提bug,将具体哪行哪个位置的问题标出,这样可以大大加快测试进展,起码可以快速使得测试通过冒烟阶段,节约一些时间。

  下面就举几个栗子说明我在走查阶段发现的几个明显的问题:

  论代码走查的重要性_第1张图片

 

首先看这段代码:

  论代码走查的重要性_第2张图片

在数据库读取的时候查询的是UNSETTLED类型的账单,但查询结果直接赋值给了名为settledBills的引用,好吧,之后的代码就都是错的了。

 

再举个栗子:

论代码走查的重要性_第3张图片

论代码走查的重要性_第4张图片  

这里调用了dubbo服务接口,对接另一个系统,传入的枚举UNSETTLE_BILL_REPAY,代表偿还未出账单的意思,但是这个代码是用来偿还已出账单的service层代码。。。

 

其实这种问题在我们项目的代码里发现的很多很多,在两个系统对接的时候,两方开发人员几乎不沟通,看哪个接口像就直接调用了,之后就都推给测试去测了,发现了问题再改,发现不了就呵呵了,不说了,都是泪。。。

总结一下,面对不靠谱、不沟通的开发,几乎没有管理的项目,一切靠测试手动发现问题实在是鸭梨山大啊。

 

你可能感兴趣的:(论代码走查的重要性)