• 2012-06-03

    聊聊Code Review

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/dreamhead-logs/216262052.html

    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的环节中,我们常说的一句话是:“线下讨论”,以此扔掉跑偏的话题。

    分享到:

    历史上的今天:

    等待发布 2008-06-03
    引用地址:

    评论

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

    这种"代码调整"你们是如何管理的?如何保证团队的成员都按照既定的规则调整自己的代码而不是偷懒,毕竟他每天还要面对新的工作量。
    回复KILLVIN_LIU说:
    没有必要管理啊!每个人在这个过程中都是学到东西,改代码对每个人来说都是学习和练习的过程。所以,在我的团队里,大家都会先改代码,然后才开始一天的工作。基本上,这些改动都会在第二天的Code Review中看到。
    2012-06-27 12:23:39
  • Scala程序设计的第157页,有一处文字错误:“读文件写真的很简单”……
    回复hiswing说:
    多谢,确实是一个错误。
    2012-06-07 07:26:09
  • 不过作为曾经的被审核者和现在的审核者来说,每日都是痛并快乐着:-D
  • 只要code review都有好处,说下这种方式的缺点吧:
    1)对审核者要求很高,懂业务,懂技术,还有有时间,成本高(其实有着不低的潜在“利润”)
    2) review只是1对1的,加上我们用英文,导致无关组员参与度不高
    3) 审核者某些时候会成为瓶颈,导致进度停滞
  • 被博主专门用博文回复,受宠若惊,我也来分享下我们现在的code review方式:)

    我们代码check in前的必须做code review,获得通过以后才能deliver,审核者一般是项目奠基者或者了解业务的技术骨干。