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

隐龙 为了一生的信念

今日默默沉于水,他日飞腾在九天...

 
 
 

日志

 
 

何合做合理的代码评审  

2012-09-03 13:15:55|  分类: 项目管理 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

虽然Code Review经常被提及,但就我个人感觉(一半从别人的博客,一半个人经历),Code Review的实际境况大多时候还是比较难看的。

更多时候,Code Review很像被存起来的酒,用的时候拿出来看看,证明有这东西,但大多时候是不用来喝的。

 

细究成因可能是来源于两个方面:

一是时间压力太大。

软件开发里可以安全打折扣的地方其实不多,文档不写很容易被看出来,代码不写程序就动都不动了。

没办法下,很多时候就只好拿Code Review开刀。

毕竟Code Review里少看两眼,多看两眼,用多少心思看,其实是个良心账,外人看不出来的。

同时,Code Review本身也确实是个费时间的活。

 

另一种成因是看不见成效。

如果把CodeReview只等价为坐在一起看代码,那么很可能Code Review中确实无法取得实效,这样做来做去,大家也就疲了,觉得这是个浪费时间的事情。

这点和上一点有点关联,一旦时间紧,就要求编码快;编码快,对具体某一个人而言,不理解的部分就变多;再加上无法预留充足的Code Review时间。

那么,除了作者外,参加Review的人对看的代码很可能是不懂的。不懂的话,也就只能糊弄,随便找点问题搪塞下。

从这个角度看,追求高生产率应该是错误的,生产率本身应该是个区间:低于某一值的是磨洋工,高于某一值的则是质量换速度。

毕竟人力有时穷尽。

 

 

单就项目时间压力这一点而言,通常并不能在项目自身范围内解决,牵涉的也比较多,暂且不论。

 

看不见成效这点却可以想点办法来改善。

改善的一个主要手段是要明确“不看什么”和“看什么”。

需要注意的是,大多时候“定义不看的”很可能比“定义需要看的”还关键。

当然这里的前提是“时间压力下,尽可能获取成果。”如果一个项目有的是时间,那就不妨把每行都找几个人仔细看看。

 

我个人感觉,CodeReview中,第一个不要干的事是“和测试抢饭碗。”

CodeReview来检测基本功能的实现是否正确这一行为本身不能讲完全错误,但至少是低效的。

从产品角度看,CodeReview应该和其它手段形成一定互补,而非是尽可能的重叠。

 

第二个不要干的事情是和“和静态测试抢饭碗”。

但凡可以依赖静态测试得出的结论的事情,在CodeReview中应该被忽略,比如:函数复杂度等。

 

这样CodeReview中应该干的事就变的清楚些了。

  •  测试很难覆盖的区域,如:多线程同步,极端条件的处理等。
  •  逻辑是否清晰,如:基本结构和设计的偏差,全局变量的使用是否合适等。
  •  静态测试无法覆盖的编码风格。编码规则中东西尽可能自动分析,但总有些东西无法自动检查,比如异常使用的是否合适等。

这类东西也只能在CodeReview中覆盖了。

 

CodeReview中,我倾向与做减法而不是加法,这样想的一个关键前提就是,项目的时间似乎总是不够,

这时候就只能让CodeReview,静态测试,单元测试这些职能进行互补,而不能让他们尽可能重叠。

  评论这张
 
阅读(524)| 评论(0)
推荐 转载

历史上的今天

评论

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

页脚

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