第四章 两人合作随笔

代码复审的步骤

在复审前——

（1）代码必须成功地编译，在所有要求的平台上，同时要编译DeBug|Retail 版本。编译要用团队规定的最严格的编译警告等级（例如C/C++中的W4）。

（2） 程序员必须测试过代码。什么叫测试过？最好的方法是在DeBugger 中单步执行。

问：有些错误处理的分支我不能执行到怎么办？

答：如果你作为作者都不能让程序执行到那里，那谁能保证这些错误处理的正确性呢？

同时也可以加上OutputDeBugString 等输出来监视程序的控制流。

（3）程序员必须提供新的代码，以及文件差异分析工具。Windiff 或VSTS 自带的工具都可以。VSTS 中可以通过Shelveset 来支持远程代码复审。

（4）复审者可以选择面对面的复审、独立复审或其他方式。

（5）在面对面的复审中，一般是开发者控制流程，讲述修改的前因后果。但是复审者有权在任何时候打断叙述，提出自己的意见。

（6）复审者必须把反馈意见逐一提出。注意，复审者有权提出很多看似吹毛求疵的问题，复审者不必每一件事都要亲自调查，开发者有义务给出详尽的回答。例如：

复审者：你在这里申请了这个资源，你是如何保证它在所有路径下都能正确释放的？

开发者：这个....我要再检查检查。

或者——

开发者：这个是这样保证的，我用了SmartPointer，然后这里有try/catch/finally....

要记住复审者是通过问这些问题来确保软件质量的，而不是有意找碴。

（7）开发者必须负责让所有的问题都得到满意的解释或解答，或者在TFS 中创建新的工作项以确保这些问题将来会得到处理。例如：

复审者：这一段代码可能会被多个线程调用，代码是thread-safe 么，我怎么没有看到对共享资源的保护？

开发者：我一时得不出结论，让我在TFS 中开一个“任务”来跟踪此事。

（8）对于复审的结果，双方必须达成一致的意见。

a. 打回去——复审发现致命问题，这些问题解决之前不能签入代码；

b. 有条件地同意——发现了一些小问题，在这些问题得到解决或记录之后，代码可以签入，不需要再次复审；

c. 放行——代码可以不加新的改动，签入源码控制服务器。

要记住复审者是通过问这些问题来确保软件质量的，而不是有意找碴。

（7）开发者必须负责让所有的问题都得到满意的解释或解答，或者在TFS 中创建新的工作项以确保这些问题将来会得到处理。例如：复审者：这一段代码可能会被多个线程调用，代码是thread-safe 么，我怎么没有看到对共享资源的保护？

开发者：我一时得不出结论，让我在TFS 中开一个“任务”来跟踪此事。

（8）对于复审的结果，双方必须达成一致的意见。

a. 打回去——复审发现致命问题，这些问题解决之前不能签入代码；

b. 有条件地同意——发现了一些小问题，在这些问题得到解决或记录之后，代码可以签入，不需要再次复审；

c. 放行——代码可以不加新的改动，签入源码控制服务器。

避免不必要的繁文缛节，我们做代码复审的目的是为了减少错误的发生，而不是找一个人来对着你的代码点头。一些简单的修改不是非得要一个复审者来走一遍形式。在项目开发的早期斤斤计较于一些细枝末节（例如：帮助文件里的拼写错误，数据文件格式不够最优化等）也是于大局无补的，但是，这些问题并不是不用处理了，我们必须建立一些优先级较低的工作项来跟踪这些事情。