一、引言
CodeReview 真的是一项苦差事，有点像吃力不讨好的活，所以很多小团队不愿意做，一般只对功能检查，而很少对代码检查。老板们也只关心功能，并不会去在意代码。但这方面在大公司或大的团队里却做的比较好。曾经在做基层管理的时候，上面要求对底下员工提交的代码全部做CodeReview，对于整个公司来说，代码风格统一，Bug 也有一定的下降。然而这几年比较小的团队去落下了，其实 CodeReview 的目的真的不是为了去刻意批斗某个Coder，而是为了团队成员之间相互了解学习，加深成员对系统的理解，使团队成员的代码更加健壮，提早发现代码缺陷。
二、CodeReview 的好处
- 提升系统或APP的可维护性
- 及早发现潜在缺陷与Bug，降低成本
- 促进团队内部知识共享，提高团队整体水平
- 评审过程对于评审人员来说，也是一种思路重构的过程，可以帮助更多的人理解系统
- 交叉审查代码，类似于结对编程，彼此都能熟悉对方模块业务，降低因人员流失的运营成本及风险
三、CodeReview 的缺点
做好 CodeReview 确实存在很多各种各样的困难，导致很多团队都能认识到它的好处却实施不下去。尤其在国内，我们几乎没听说过严格把 CodeReview 作为一项研发制度或规则要求的公司。即使强大如阿里，甚至对外推出很多编码规范，但内部的员工有多少按规范来做事呢？反正我所接触的阿里人很少按规范。
- 评审人员需要投入大量的时间
- 早期团队成员可能会不习惯，甚至会影响项目进度
- 有些老板，特别是小团队的老板，不愿意投入
四、如何做 CodeReview
抛开制度上的强求，我们只谈CodeReview。
保持简短，对开发人员来说，一次只检查少于200-400行的代码（半小时左右），超过 400 行将需要更多时间，并且会使评审者感觉疲倦，如果代码审查过程需要超过一个小时，您可以将其分成几个较小的模块。
开发者应在开始审核之前注释源代码：通知同事应检查哪些文件，防止再次评审以前审查过的代码。
做一个要检查的清单：在代码审查过程中，清单上应该有预期需要检查代码的目标（代码的安全性，业务逻辑实现和用户访问权限等等 在评审的过程中可）和代码的作者和评审者，问题的安全级别 需要何时修复，修复确认人和确认时间。
让它无痛苦。始终确保代码易于理解，不需要额外的评论。还为审阅者提供背景。我们通过GitHub上的Pull Request功能提交我们的代码进行审查。
定义你的目标。您可以专注于代码所需功能的表示; 避免代码味道; 关于代码与风格指南的相关性。但是要始终专注于对你最重要的事情，并尽力写出最好的代码。
五、CodeReview的注意点
5.1 CodeReview要求团队有良好的文化
团队需要认识到代码审查是为了提高整个团队的能力，而不是针对个体设置的检查“关卡”。“A的代码有个bug被B发现，所以A能力不行，B能力更好”，这一类的陷阱很容易被扩散从而影响团队内部的协作，因此需要避免。另外，代码审查本身可以提高开发者的能力，让其从自身犯过的错误中学习，从他人的思路中学习。如果开发者对这个流程有抵触或者反感，这个目的就达不到。
5.2 带着问题去进行CodeReview
我们在每次CodeReview中，要求审查者利用自身的经验先思考可能会碰到的问题，然后通过审查工作验证这些问题是否已经解决。一个窍门是，从用户可见的功能出发，假设一个比较复杂的使用场景，在代码阅读中验证这个使用场景是否能够正确工作。使用这个技巧，可以让审查者有代入感，真正的沉浸入代码中，提高效率。大家都知道看武侠小说不容易瞌睡，而看专业书容易瞌睡，原因就是武侠小说更容易产生代入感。有的研究建议每次树立目标，控制单位时间内审核的代码数量。这个方法在我们的实践中显得很机械和流程化，不如上面的方法效果好。
5.3 提交代码前自我 CodeReview
所有团队成员在提交代码给其他成员审查前，必须先进行一次审查。这次自我修正形式的审查除了检查代码的正确性以外，还可以完成如下的工作：
- 对代码添加注释，说明本次修改背后的原因，方便其他人进行审查
- 修正编码风格，尤其是一些关键数据结构和方法的命名，提高代码的可读性
- 从全局审视设计，是否完整的考虑了所有情景。在实现之前做的设计如果存在考虑不周的情况，这个阶段可以很好的进行补救
我们在实践中发现，即使只有原作者进行 CodeReview，仍然可以很好的提高代码质量。
5.4 所有的问题和修改必须由原作者进行确认
如果在 CodeReview 中发现问题，务必由原作者进行确认。这样做有两个目的：
- 确认问题确实存在，保证问题被解决
- 让原作者了解问题和不足，帮助其成长
有些时候为了追求效率，有经验的审查者更倾向于直接修改代码乃至重构所有代码，但这样不利于提高团队效率，并且会增加因为重构引入新 Bug 的几率，通常情况下我们不予鼓励。
5.5 使用好的工具进行轻量级的CodeReview
“工欲善其事，必先利其器”。使用好 CodeReview 可以达到事半功倍，因工具比较多，不展开说明。
六、后记
CodeReview 追求的是质量而不是数量。不要过分要求程序员做代码审查。同时，CodeReview是针对代码，不是针对人。CodeReview是一种学习，是表扬，是获得反馈。
CodeReview 是一种十分社交性的活动。代码审查应该是有趣的，不要让它变的无聊。