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

建议继续学习：

1. 从Code Review 谈如何做技术    (阅读：3681)
2. 探讨前端代码Review    (阅读：1967)