概述
前两骗文章，分别从代码编写、研发管理的角度，探讨了如何应对大型复杂软件开发。在研发管理这一部分，又讲到了比较重要的几点，它们分别是编码规范、单元测试、持续重构和 Code Review。其中，前三点在前面的文章中都有比较详细的讲解，而唯独 Code Review 还没有讲过，本章就和你补充下这部分的内容。
有很多人对 Code Review 是否定的态度，认为 Code Review 比较浪费时间，往往会虎头蛇尾，不可能在企业找那个很好的落地执行。我觉得问题主要还是出自认知上。
所以，本章并不打算讲关于如何 Code Review 的方法论，而是一起探讨下，为什么要进行 Code Review，Code Review 的价值在哪里，让你重视、认可 Code Review。因为我觉得，只要从认知上接受了 Code Review，对于开发人员来说，搞清楚如何做 Code Review 并不是很难的事情。而且，Google 也开源了它自己的 Code Review 最佳实践，网上很容易可以搜索到，你完全可以照着来做。
为什么如此强调 Code Review？
Code Review 中文叫代码审查。据我了解，国内绝大部分企业，很少有将 Code Review 执行的很好的。特别是在一些需求变动大、项目工期紧的业务开发部门，就更不可能有 Code Review 流程了。代码写完之后，随手就提交上去，然后丢给测试玩命的测，发现 bug 再修改。
相反，一些外企非常重视 Code Review，特别是大厂，Code Review 落地执行地非常好。下面就讲一讲 Code Review 的价值，希望你能从中有所收获。
1.Code Review 践行 "三人行必有我师"
你可能会觉得，团队中的资深员工或技术 leader 的技术比较牛，写的代码很好，他们的代码就不要 Review 了，重点 Review 资历浅的员工的代码就可以了。实际上，这种认知是不对的。
中国有句老话，"三人行必有我师" ，我觉得用在这里非常合适。即便自己觉得写得已经很好的代码，只要经过不停地推敲，都有持续改进的空间。
所以，永远不要觉得自己很厉害，写的代码就不需要别人 Review 了；永远不要觉得自己水平很一般，就没资格给别人 Review 了；更不要觉得技术大牛让你 Review 代码只是缺少你一个 "approve"，随便看看就可以了。
2.Code Review 能摒弃 "个人英雄主义"
在一个成熟的公司里，所有的架构设计、实现，都应该是一个团队的产出。尽管这个过程可能会由某个人来主导，但应该是整个团队共同智慧的结晶。
如果一个人默默地写代码提交，不经过团队的 Review，这样的代码蕴含的是一个人的智慧。代码的质量完全依赖于这个人的水平。这就会导致代码质量参差不齐。如果经过团队多人 Review、打磨，代码蕴含整个团队的智慧，可以保证代码按照团队中的最高水准输出。
3.Code Review 能有效提高代码的可读性
前面反复强调，在大部分情况下，代码的可读性比任何其他方面（如扩展性等）都重要。可读性好，代码后期维护成本低，线上 bug 容易排查，新人容易熟悉代码，老人离职时代码容易接手。而且，可读性好，也就说明代码足够简单，出错的可能性小、bug少。
不过，自己看自己的代码，总会觉得很容易读懂，但换另一个人来读你的代码，他可能就不这么认为了。比较自己写的代码，其中涉及的业务、技术自己很熟悉，别人不一定会熟悉。既然自己对可读性的判断容易出现错觉，那 Code Review 就是一种考察代码可读性的很好手段。如果代码审查者很费劲才能看懂你写的代码，那就说明代码的可读性有待提高了。
还有，不知道你有没有这样的感受，写代码时，时间一长，改动的文件一多，就感觉晕乎乎的，脑子不清晰，逻辑不清晰？
有句话讲，"旁观者清，当局者迷"，说的就是这个意思。Code Review 能有效地解决 "当局者迷" 的问题。在正式开始 Code Review 之前，我们将代码提交到 Code Review 的工具界面之后，所有的代码改动都放到了一起，看起来一目了然、清晰可见。这个时候，还没等其他同事 Review，自己就能发现很多问题。
4.Code Review 是技术传帮带的有效途径
良好的团队需要技术和业务的 "传帮带"，那如何来做 "传帮带" 呢？业务上面，我们可能通过文档或口口相传的方式，那技术呢？如何培养初级工程师的技术能力呢？
Code Review 就是一种很好的途径。每次 Code Review 都是一次真实案例的讲解。通过 Code Review ，在实践中将技术传递给初级工程师，比让他自己学习、自己摸索来得更高效。
5.Code Review 保证代码不止一个人熟悉
如果一段代码只有一个人熟悉，如果这个同事休假了或者离职了，代码交接起来就比较费劲。有时候，我们单纯只看代码还不懂，又要跟 PM、业务团队、或者其他技术团队，再重复来一轮沟通，搞得其他团队的人都很烦。而 Code Review 能保证任何代码同时至少有两个同事熟悉，互为备份。
6.Code Review 能打造良好的技术氛围
提交代码 Review 的人，希望自己写的代码足够优秀，比较被同事 Review 出很多问题，是件很丢人的事情。而做 Code Review 的人，也希望自己尽可能地提出有建设性意见，展示自己的能力。所以，Code Review 还能增进技术交流，活跃技术氛围，培养大家的极客精神，以及对代码质量的追求。
一个良好的技术氛围，能让团队有很强的自驱力。不用技术 leader 反复强调代码质量有多重要，团队中的成员就会自己主动去关注代码质量的问题。这比制定各种规章制度、天天督促执行要更加有效。实际上，好的技术氛围也能降低团队的离职率。
7.Code Review 是一种技术沟通方式
Talk is cheap, show me the code.
怎么 "show"，通过 Code Review 工具来 "show"，这样也方便别人反馈意见。特别是对于跨不同办公室、跨时区的沟通，Code Review 是一种很好的沟通方式。白天写的代码，明天来上班时，其他同事已经帮我 Review 好了，我就可以改动提交，继续写信的代码了。这样的协作效率会很高。
8.Code Review 能提高团队的自律性
在开发过程中，难免会有人不自律，存在侥幸心理：反正我写的代码也没人看，随便写写就提交了。Code Review 相当于一次代码直播，曝光 dirty code，有一定的威慑力。这样大家就不敢随便应用一下就提交代码了。
如何在团队中落地执行 Code Review？
有人认为，Code Review 流程太长，太浪费时间，特别是工期紧的时候，今天改的代码，明天就要上线，如果要等同事 Review，同事可能没时间，这样就来不及。这个时候该怎么办？
我所经历的项目还没一个是因为工期紧 ，导致没有时间 Code Review 的。工期都是人排的，稍微松点就好了。关键还是在于整个公司对 Code Review 的接受程度。而且，Code Review 熟练了之后，并不需要花费太长的时间。尽管开始做 Code Review 时，可能因为不太熟练，需要有一个 checklist 对照着来做。起步阶段可能会比较耗时。但当你熟练之后，Code Review 就像盲打键盘一样，你已经忘记了哪个手指按的是哪个键了，扫一遍代码就能揪出绝大部分问题。
有人认为，业务一直在变，今天写的代码明天可能就要改，代码可能不会长期维护，写得太好也没有。这种情况是不是就不需要 Code Review 了？
这种现象在游戏开发、一些早期的创业公司或者项目验证阶段比较常见。项目讲求短平快，先验证产品，再优化技术。如果确实面对的还只是生存问题，代码质量确实不是首要的，特殊情况下不做 Code Review 是可以的。
有人说，因为成员技术水平不高，过往也没有 Code Review 的经验，不知道 Review 什么，也 Review 不出什么。自己代码都没写明白，不知道什么的代码是好的，什么样的代码是差的，更不要说 Review 别人的代码了。在 Code Review 时，团队成员大眼瞪小眼，只能 Review 点语法，形式大于效果。这种情况怎么办？
这种情况也挺常见。不过没关系，团队技术水平都是可以培养的。我们可以先让资深的同时、技术好的同事或者技术 leader，来 Review 其他所有人的代码。Review 的过程本身就是一种 "传帮带"。慢慢地，整个团队就知道该如何 Review 了。虽然这可能会有一个相当长的过程，但如果真的想在团队中执行 Code Review，这不失为一种 "曲线救国" 的方法。
还有人说，刚开始 Code Review 时，大家都还挺认真，但时间长了，大家觉得这事跟 KPI 无关，而且我还要看别人的代码，理解别人写的代码的业务，多浪费时间啊。慢慢地，Code Review 就变得流于形式了。有人提交了代码，随便抓个人 Review。Review 的人也不认真，随便扫一眼就点 "approve"。这种情况该如何应对？
首先，要明确的告诉 Code Review 的重要性，要严格执行，让大家不要着急，适当的时候可以 "杀鸡儆猴"。其次，可以像 Google 一样，将 Code Review 间接地跟 KPI 、升职等联系在一起，高级工程师有义务做 Code Review，就像有义务做技术面试一样。再次，想办法活跃团队技术氛围，把 Code Review 作为一种展示自己技术的机会，带动起大家对 Code Review 的积极性，提供大家对 Code Review 的认同感。
Google 的 Code Review 是做的很好的，可以说是谷歌保持代码高质量最有效的手段之一了。Google 的 Code Review 非常严格，多一个空行，多一个空格，注释有拼错的单词，变量命名得不够好，都被被指出来要求修改。之所以如此吹毛求疵，并非矫枉过正，而是要给大家传递一个信息：代码质量非常重要，一点都不能马虎。
总结
本章，主要讲解了为什么要做 Code Review，Code Review 的价值在哪里。总结如下：
- Code Review 践行 "三人行必有我师"
- 能摒弃 "个人英雄主义"
- 能有效提高代码可读性
- 是技术传帮带的有效途径
- 能保证代码不止一个人熟悉
- 能打造良好的技术氛围
- 是一种技术沟通方式
- 能提供团队的自律性
此外，还对 Code Review 在落地执行过程中的一些问题，做了简单的问答。希望在你 Code Review 遇到同样的问题时，能对你有所帮助。