聊聊Code Review

标签: code review | 发表时间:2012-06-03 13:45 | 作者:dreamhead
分享到:
出处:http://dreamhead.blogbus.com

hopesfish评论《 那一点的调用》时,问了一个关于Code Review的问题:

想请教一下,TW的筒子是如何做code reivew或者鼓励客户做code review的?我在翻阅博主的帖子的时候,似乎对这块没有特别强调,而是更多偏重于TDD,我觉得TDD的问题是一碰到没有责任心的程序猿,就很容易流于形式了

谈及TDD的好处时,其中之一就是随时随地的Code Review,所以,貌似TDD是不需要Code Review的。但实际上,TDD和Code Review是两个正交的维度,做TDD并不妨碍Code Review。

这里就来聊聊我所在的项目是如何做Code Review的。我们有两种Code Review:Daily Code Review和Weekly Code Review。之所以有两种Code Review,因为每种Code Review的目的是不同的。

Daily Code Review

顾名思义,这是一种每天都做的Code Review。它的目的是让项目组全体成员了解每天的项目进展。

每天早上,运用git(这里可以替换成你所用的版本控制软件)的diff功能,找出前一天修改。全项目组的人在一起,逐行浏览这些修改。每当过到一处修改,这段代码的修改者就会针对修改,介绍一下这是哪个功能,为什么要做这些修改。项目组的其他人如果对这段代码有异议,都可以提出自己的问题。

这种Code Review使用的diff功能,了解的基本上只是一个片段,所以,关注点基本上是Clean Code。最经常出现的问题是,这段代码为什么写成这样。对于项目组的新人而言,这种Code Review是一个非常好的学习Clean Code以及了解项目隐含编码约定的机会。

Daily Code Review结束之后,每个人会针对其他人提出的修改意见对代码进行调整。在开始新一天的工作之前,最大程度地保证了代码库的整洁。

Weekly Code Review

诚如之前所述,Daily Code Review只能了解一个片段,人们缺乏对一个功能或一个故事的整体认识。Weekly Code Review弥补了这种缺陷。

Weekly Code Review更类似于许多企业的传统Code Review方式。由专人(一个人或一对pair)选取一个近期开发比较大的功能(或故事),组织全项目组的人进行Review。

在这个过程中,组织者会带领所有人浏览针对这个功能的相关代码。我们的主要关注点是让项目组的所有人对这个功能有所了解。这时项目组成员,也会从业务逻辑,以及局部设计的角度对代码进行分析,提出一些改进建议。如果过程中出现了一些难于理解的部分,组织者要负责为大家答疑解惑。

同样,在Weekly Code Review中发现的问题,也会被修正到代码之中。

无论是Daily Code Review还是Weekly Code Review,最容易出现的问题都是时间控制。如前所述,不同类型的Code Review有其侧重点,所以,讨论的组织者要负责把握讨论的方向,防止发散,在Code Review的环节中,我们常说的一句话是:“线下讨论”,以此扔掉跑偏的话题。

相关 [code review] 推荐:

聊聊Code Review

- - 梦想风暴
hopesfish评论《 那一点的调用》时,问了一个关于Code Review的问题:. 想请教一下,TW的筒子是如何做code reivew或者鼓励客户做code review的. 我在翻阅博主的帖子的时候,似乎对这块没有特别强调,而是更多偏重于TDD,我觉得TDD的问题是一碰到没有责任心的程序猿,就很容易流于形式了.

Java Code Review清单

- - ImportNew
使用可以表达实际意图(Intention-Revealing)的名称. DRY(Don’t Repeat Yourself)原则,(拒绝重复). 用代码来解释自己的做法(译者注:即代码注释). *参考自: http://techbus.safaribooksonline.com/book/software-engineering-and-development/agile-development/9780136083238.

我的code review规则

- vento - 我的宝贝孙秀楠 ﹣C++, Lua, 大连,程序员
1) 是否有语法错误,编译错误,编译警告. 做法:下载最新代码,将编译警告级别提升到最高,检查output信息. 2)是否符合需求,完成requirement文档要求的内容,不能多,也不能少. 注意:即使发现有问题代码,如果与需求关联不大,不要涉及. 应该让每次enhancement和bug fix最简洁,牵涉范围最小,影响到组件最少.

Code Review那些事儿

- - 非技术 - ITeye博客
       曾经有一段 垃圾代码放在我的面前,我没有拒绝,等我真正开始接手的时候我才后悔莫及,程序员最痛苦的事莫过于此. ---------改编于周星星的经典台词.       虽然有点夸张,但编码界确实大大存在这种情况,每当接手别人的代码,都有一种想重新写一遍的感觉,等到别人再来接手你的代码时,同样的感觉.

[原]强制 code review:reviewboard+svn 的方案

- - 赖勇浩的编程私伙局
赖勇浩( http://laiyonghao.com). 我们团队在开发《天下盛境》项目的时候,制定和执行了比较好的 code review 策略,总结下来有几个优点:一是代码风格可控,代码质量有一定提升;二是新员工入职后能够得到更多人的指导,成长非常快;三是小 bug 频出的情况比我做《天》之前的项目少了至少一个数量组.

代码审查(Code Review)清单

- - 博客 - 伯乐在线
代码审查可以帮助提高代码质量,避免由于代码习惯而造成的 bug. 下面列出的这些要点因该可以作为大部分代码审查的指导,如果是 Java 应用的话,这些建议应该被视作最佳实践. Javadoc 应该在每一个类和方法中添加. 如果是修复某个 bug,应该添加 bug ID. 走捷径的方法或者复杂的逻辑要有解释.

从Code Review 谈如何做技术

- - 酷 壳 - CoolShell.cn
(这篇文章缘由我的微博,我想多说一些,有些杂乱,想到哪写到哪). 这两天,在微博上表达了一下Code Review的重要性. 因为翻看了阿里内部的Review Board上的记录,从上面发现Code Review做得好的是一些比较偏技术的团队,而偏业务的技术团队基本上没有看到Code Review的记录.

测试技术中CODE REVIEW的重要性

- - CSDN博客推荐文章
        [近期关注App自动化测试,欢迎交流,本博客文章版权归作者所有,转载请联系]     .         最近有网上的朋友向我咨询作为测试员是否应该跳槽,   首先我觉得应该向大家介绍一下什么是测试工程师,  什么是测试员,   在国内的一些中型企业并没有特别的指明.   这里测试工程师主要指测试开发工程师, 主要包括两类,  其一是测试软件开发的工程师,  其二是自动化测试脚本开发和维护的工程师,   而测试员主要指单纯编写/管理测试用例,  或是手工测试人员, 一些国内的大中型网络视频公司仍然在用纯手工测试,我感觉到很汗颜.

Clean-Code: 注释

- We_Get - 博客园-首页原创精华区
别给糟糕的代码加注释-----------------重新写吧. 这是书中的关于注释一章的第一句话,怎么说呢,这句话个人感觉很对,但是实际上却很少这么做,. 糟糕的代码不是自己写的,别人写的代码,还是让别人自己去维护吧,出了问题也是别人的. 糟糕的代码目前可以正常工作,软件开发中有一条古老哲言:如果它能工作就不要动它,很多程序员都遵守这条准则.