常飘在天上的代码评审CodeReview

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

创新互联专业为企业提供利辛网站建设、利辛做网站、利辛网站设计、利辛网站制作等企业网站建设、网页设计与制作、利辛企业网站模板建站服务，十余年利辛做网站经验，不只是建网站，更提供有价值的思路和整体网络服务。

一是时间压力太大。

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

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

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

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

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

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

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

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

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

毕竟人力有时穷尽。

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

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

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

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

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

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

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

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

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

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

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

 测试很难覆盖的区域，如：多线程同步，极端条件的处理等。

 逻辑是否清晰，如：基本结构和设计的偏差，全局变量的使用是否合适等。

 静态测试无法覆盖的编码风格。编码规则中东西尽可能自动分析，但总有些东西无法自动检查，比如异常使用的是否合适等。

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

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

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

文章标题：常飘在天上的代码评审CodeReview
转载源于：http://www.shufengxianlan.com/qtweb/news44/54794.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联