我这里想聊的‘代码审查’，即code review，不是测试人员拿个静态代码分析工具，查查代码是否符合命名规范和格式要求之类的流程。而是技术人员之间对代码进行讨论的方式和渠道。

国内的项目很少会用到code review工具，尽管已经有不少开源免费的可供使用。我很赞同《Code Review中的几个提示》文中的以下两个观点。PS.陈皓是我很喜爱的技术人员之一:)

• Code reviews 不应该承担发现代码错误的职责
• Code reviews 不应该成为保证代码风格和编码标准的手段。

既然我认为code review本质上是一种讨论方式，那么它在项目开发过程中应该有以下特点：

它应该是频繁发起的。

在开发人员check-In代码之前，就把编译好的代码发给内部团队review。

review过程简单易行，它不能成为开发人员的负担。

最忌讳是把一堆人拉到会议室，对着投影出的几十行代码蹙眉沉思。最好的方式是能通过特定工具发送邀请，别人想啥时review就能review。我一向觉得写代码是很讲究感觉的工作，所以review也不应该是一种强制性的行为。你可以邀请更多人帮你review，或许只有1-2人响应你，对代码发表意见；对于其他“沉默人士”，除非你需要得到他们的权威意见，否则不要强求。

某一个变更/功能的code review或许会经历多个迭代。

因为你可能需要基于他人的建议更新代码，发起第二次甚至更多次的review，以求达成共识。而针对同一主题多次迭代的讨论，都应当整理到一起，以便检索。

作为项目活动，在code review过程中要标识出review进行的状态，记录下大家的具体意见。

从发起到结束，可能会经历几天甚至几周的时间，谁正在review，谁提出了意见在等发起人回应，以及发起人对意见的回应，这些内容都应该让参与review的干系人一目了然。

review的主要目的是讨论代码在逻辑上是否可行，抑或有更优的解决方案。当然，不排除会发现一些错误。

这一点我与陈皓的观点一致，review就是review，不能代替testing，更不能确保代码是完全没问题的。

一个code review是否终结，是发起人决定的。

既然review是某个开发人员发起的，而Ta是这部分代码的Owner，那么Ta也应该是这次review的Owner。

code review的最终结果，要么sign-off，即达成共识，供测试通过之后可以check-In/deploy；要么是decline，即整体打回重做，放弃本次review。

正如我上面提到的，review最终结果是发起人决定的，也就是说sign-off/decline这些只是参与review的人提出的个人意见，代表Ta看过代码后的个人最终评定。而代码到底怎样，重写了还是迁入了，项目经理还是管review发起人问。当然，理想状态是发起人在特定工具上设置completed/cancelled结果，告知干系人。

code review可以作为员工素养的一种体现。经常帮别人review的人，一定是很有团队精神的；而在review过程中经常能提出有价值的问题和建议的，一定是功底了得。经过某人sign-off之后的代码，经测试一般没有大的纰漏，而某人sign-off之后的代码，总会引发其他问题……有时你会发现，某人提交了一次code review，若干天之后，无人响应；那或许是因为这个模块的业务逻辑其他人不太清楚，不敢擅自发表意见。此时项目经理应当得到重视，因为每个模块至少应当有两人了解，否则会有极大的风险，若此人休假或离职，会对项目有严重影响。

code review是我在2012年，也就是从业2年多才意识到它的重要性。然而我在09年就接触了TFS，却一直不知有个shelf set功能，来帮助code review。