有家叫作 SmartBear 公司, 我用过他们的一款代码审查的工具 Code Collaborator , 对于代码审查，觉得他们总结的十条最佳实践挺不错， 顺手翻译如下， 未严格遵循原文翻译， 并加了点评注， 原文参见 https://smartbear.com/learn/code-review/best-practices-for-peer-code-review

1.一次只审查小于 500 行的代码

2.不要着急， 代码评审的速率最好小于每小时500行

3.一次审查不要超过一个小时

4. 设立目标并检查相应的测试及度量数据

如何你的实现某个功能的， 跑几个相应的集成测试
如果你是优化某个性能的， 给出一个性能优化数据
如果你是应对某种异常的， 给出相应的异常测试用例

在代码审查结束后， 也给出一个总结：

• 花费了多长时间（Man Hour）,
• 每小时审查了多少行代码，
• 找出了多少bug （平均每百行bug率是多少）
• 代码的相关测试是否充分和有效率
• 发现了多少设计上的问题
• 发现了多少可靠性与异常保护方面的问题
• 发现了多少有关可理解性和可维护性的潜在问题

5.作者应该在代码审查之前对代码给出相应的说明和注解

6. 使用静态代码检查工具和检查表

先自查， 再互查

7. 建立一个跟踪修复所发现问题的流程

比如

• 创建一个git issue 或报一个bug来跟踪问题，指定专人对修复 bug 的代码作再次审查
• 对设计或需求上的问题作出后续的安排，如需求或设计评审会议
• 对疑难问题创建一个任务进行后续研究
• 等等

8.培育一个积极的代码评审文化

代码评审可能会遭遇抵触情绪， 造成同事之间关系紧张， 应该树立这样一种观念， 越早发现问题越好，代码评审是最有效率的提高代码质量， 提升代码水平的手段， 互相协作和学习才可以共同进步。
在代码评审时， 要对事不对人， 保持谦逊和礼貌， 代码评审的结果不可作为业绩考核的数据标准

9. 重视代码评审的潜在作用

有人会检查你的代码， 自然会驱动你写好代码。为了面子， 你也会有更多动力写出更优雅的代码

10. 实践轻量级的代码评审

无需每次开会来审查代码， IM, Pull Request, 面对面的一起结对审查代码都是不错的方法

另外，说点代码评审的个人感受

1. 适可而止

几乎没有十全十美无可挑剔的代码，总是有些许改进的空间，不必过度优化，过度设计，把握住基本原则，适可而止，关键要看是否变得更好，以后是否留下隐患或者更大的麻烦

2. 和谐共赢

人性的弱点在于喜欢表扬，反感批评，代码评审要对事不对人，讲究方式方法，顾及到别人的感受，先肯定，再否定，给别人台阶下，谁敢说自已的代码没毛病，少说感觉，多讲原则，不提个人喜好，只讲利弊分析

3. 有始有终

代码评审会议一定要有记录，有跟踪，有始有终，每一条反馈意见都要落实，代码一定要有类似于pull request 的比较评注工具，发现的常见问题最好整理总结出来，作为参考比如Checklist, FAQ 或者 best practice