没有人否认code review（代码评审、复查） 对提高代码质量的作用，但是如何进行code review? 这里 确实存在一些方法和技巧。方法不当，会浪费大量时间、造成低效率；流程过紧，会大大降低生产力，流程过松，很难知道code review的效果，甚至有没有进行code review,都很难判断。
这里有11条代码复审的最佳实践：
- 一次检查少于200～400行代码
- 努力达到一个合适的检查速度：每小时少于300～500行代码
- 有足够的时间、以适当的速度、仔细地检查，但不宜超过60～90分钟
- 在复审前，代码作者应该对代码进行注释
- 建立量化的目标并获得相关的指标数据，从而不断改进流程
- 使用检查表（checklist）肯定能改进双方（作者和复审者）的结果
- 验证缺陷是否真正被修复
- 管理人员要营造良好的氛围（文化），使大家可以积极地对待缺陷的发现，发现足够多的缺陷，只关心问题是什么、怎样引起的，而不关心是谁写的代码
- 清楚度量工具（"Big Brother"）的作用——度量工具是双刃剑，要小心使用
- 自我约束：即使没有时间完成所有代码的检查，也应该尽可能去做，哪怕是一部分
- 轻量级的code review是高效率的、可行的，并能有效地发现缺陷
详细内容参见 [PDF] Best Practices for Peer Code Review ( www.SmartBearSoftware.com)
或 Code Reviews － http://dotnet.org.za/cjlotz/archive/2007/08/28/code-reviews.aspx
有一个评论，对大家也有帮助，如强调code review的目标、代码静态分析工具的使用等：
I think the first thing you need to figure out is what kind of errors are you expecting to find during inspections. It must exist a clear idea of the goal of the review and all participants should share this idea. If this is not defined you may have reviews wasting time in discussions about variable names, indentation, code comments, message descriptions, or any other topic.
In my company for example, we don't look for code conventions compliance, we use automated tools to ensure that. We run static analysis tool on our code before inspections, therefore we don't look for the type of errors that this tool can easily report. But we do look for compliance with the design: is the code implementing the defined design appropriately? Are all exception conditions handled following the design?
One useful thing that I did in the past to define our goal for code reviews is to read different code inspection checklists available online and identify the items that I considered useful for our reviews. Then, based on that list I agreed with the team the aspects that we should check in our code reviews. In that way we focused our effort and everyone was on the same page during the review.
另外参考文章：