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