是否要作Code Review？与BAT资深架构师争论以后的思考

关注个人微信公众号：小争哥，获取更多、更新的技术、非技术分享。
做者：前Google工程师，5万人订阅《数据结构和算法之美》专栏做者。
但愿经过我加速你的技术、职场进步。

Code Review中文叫代码审查，据我所知在不少互联网企业里面几乎没有很好的实践，包括不少像BAT同样的大厂，特别是一些业务开发部门，都没有Code Review流程，代码写完以后随手提交，而后丢给测试狠命测．

以前跟一个有十几年开发经验的现BAT某家的资深员工提起Code Review时，其很笃定的讲不可能很好的执行，比较浪费时间，有始无终等等，一顿否认，又当我提起在Google内部开发中Code Review是一个执行的很好且已经习觉得常的开发流程时，他居然倚老卖老的说绝对不相信．

一个技术不错，号称架构师，玩转各类框架，中间件的资深IT从业者，竟然对Code Review有如此的偏见，是哪里出了问题，这也是我写这篇文章的缘由。本文不是一篇讲如何作Code Review的方法论，尽管有所涉及，但更多的是对Code Review执行过程当中不少团队会遇到的一些问题的思考。

1. Code Review的意义有多大？

首先来讲下Code Review的意义，当开发团队对Code Review承认了，意识到它的必要和好处了，我想，弄清楚如何快速有效的Code Review，对充满高智商、高学习能力的IT界工程师来说，也就不是什么难事了。

1）三人行必有我师

永远不要以为本身很牛逼，或者代码很牛逼，不须要别人Review；也永远不要以为本身水平通常，没有资格给别人Review；更不要以为大牛让你Review代码就只是缺乏你的一个approve，能够随便扫一眼就LGTM（looks good to me）了。

谷歌在Code Review方面执行的很好，尽管谷歌的工程师的平均研发水平都很高，但你会发现，只要是提交Review的代码，照样会有不少comment（修改意见）。即使本身以为足够牛逼的代码，只要通过不停的推敲，都是有持续改进的空间的。

2）高手之间的过招在细节

只要对技术有追求的团队，就不能把开发当成外包：只要代码能够运行就提交，黑盒狠命测一把，验出bug再修复。高手之间过招看的是细节。不一样水平的团队，开发相同的业务或者框架，开发出来的东西虽然都能跑，但在可读性，扩展性，性能，可靠性等各类非功能性方面均可能差异不少。

3）Code Review是摒弃我的英雄主义的做坊式开发模式的有效手段

在一个成熟的公司里，全部的架构设计、实现，都应该是一个团队的产出。尽管这个过程可能会有某我的来主导，但应该是通过整个团队共同智慧的结晶。

若是一我的默默的写代码提交，不通过团队的Review，这样的代码蕴含的是一我的的智慧。代码的质量彻底依赖于这我的的技术水平。这就会致使代码质量层次不齐。若是通过团队多人Review，打磨，则代码蕴含的是整个团队的智慧，能够保证代码按照团队中的最高水准输出。

4）Code Review过程是对代码可读性的考察

我以为，代码的可读性可能比任何方面（扩展性等）都重要。可读性好，表明了后期维护成本低，线上bug容易排查，新人容易熟悉代码，老人离职时代码容易接手，并且可读性好，也说明代码足够简单，出错可能性小，代码的组织架构合理。

而Code Review是考察代码的可读性的一种很好的手段。若是代码审查者（Reviewer）很费劲才能看懂你的代码，说明这段代码的可读性就有待提升了。

5）Code Review能够提升代码质量

这个不少人都承认，前面也讲到了。不过我补充一点个人体会：有句名言：旁观者清，当局者迷。本身写代码的时候，写的晕乎乎的，有时候将代码提交review board（code review的工具界面）以后，本身的改动都放到一块，清晰可见，一目了然，有时候尚未等其余同事review，本身就先发现了不少问题。

6）Code Review过程是一种mentor（传帮带）的有效途径

团队讲求传帮带，如何来作呢？固然，业务上面，咱们可能经过文档，口口相传，那技术呢？如何培养初级工程师的技术能力呢？Code Review就是一种很好的途径，每次Code Review的过程都是一次真实的案例讲解，是从大牛身上学习技术的很好途径。

7）Code Review保证不止一人对代码熟悉

若是一段代码只有一我的熟悉，若是这个同事休假了离职了，交接起来就比较费劲，有时候单纯看代码还看不大懂，又要跟PM、业务团队、或者其余技术团队，再重复来一轮沟通，搞的其余团队的人都很烦你。而Code Review保证任何代码都至少同时有两个同事熟悉，除非两个同事同时离职:（

8）Code Review能够打造良好的技术氛围

提交代码Review的人，但愿本身写的代码足够牛逼，毕竟被同事Review出不少烂代码，是件很丢人的事情。而作Code review的人，也但愿本身尽量的提出有建设性第一件，展现本身的能力。这自己就能增进技术交流，活跃技术氛围，培养你们的Geek精神，对代码优美的追求。

9）Code Review是一种沟通方式

Talk is cheap，show me the code。怎么"show"，经过Code Review工具来"show"，这样也方便别人反馈意见。特别是跨不一样办公室、跨时区的沟通，Code Review是一种很好的沟通方式。我今天白天写的代码，明天来上班的时候，跨时区的同事已经帮我Review好了，岂不是感受很好。

10）Review提升你们自律性

开发过程不免有人不自律，或者偶尔有侥幸心理，反正也没人看，随便写写就提交了。Code Review过程至关于一次代码直播，曝光dirty Code，有必定的威慑力，你们就不敢随便应付一下就提交代码了。

2. Code Review反对声音有哪些？

上面讲了这么多Code Review的意义，虽然大部分人都承认，但仍是有不少反对的声音，咱们来看看都有哪些反对的声音？

1）有人认为Code Review流程太长，太浪费时间，特别是业务逼，工期紧的时候，今天改的代码，明天就要上，若是等同事Review，同事还有可能没时间。

我所经历的项目，尚未一个由于工期紧致使没有时间Code Review的。并且Code Review熟练以后，并不须要花费太长的时间。尽管开始作Code Review的时候，你可能由于不熟练，须要有一个check list对照着来Review，比较耗时，但当你熟练以后，Code Review就像键盘盲打同样，你已经忘记了哪一个手指按的是哪一个键了，扫一遍代码就能揪出绝大部分问题。

2）有人认为有了黑盒测试，写的代码给测试团队测试就ok了，Code Review没有必要，ROI（投入产出比）不高。

黑盒测试只能测试代码的正确性，对于不少非功能性的，好比代码的可读性，扩展性，组织结构是否合理，性能问题等都是没法考察的。

3）有人认为业务一直在变，今天写的明天可能就改，代码有可能不会维护好久，代码写得太好也没用。

这种现象在游戏开发、一些早期的创业公司、或者项目验证阶段比较常见，讲求短平快，先验证产品，再优化技术，若是确实面对的还只是生存问题，代码质量确实不是首要的，特殊状况下，不作Code Review是支持的！

3. Code Review如何落地执行？

知易行难，有些leader已经认识到Code Review的必要性，但执行起来又困难重重，下面罗列了我所经历的一些困难，以及相应的应对策略。

1）团队成员水平比较低，不知道Review什么，也Review不出什么。本身代码都没写明白，不知道什么是好的代码，什么是差的，更不要说告诉别人了，大眼瞪小眼，只能Review点语法的了。

这种状况也挺常见，不过不要紧，团队的技术水平都是能够培养的。咱们能够先让资深同事。技术好的同事、或者leader，来review其余全部的人的代码。Review的过程也是一种mentor的过程，慢慢的你们都知道哪样的代码有问题，应该从哪些方面Review。虽然这可能会有一个至关长的过程，但若是真想在团队中实行Code Review，这不失是一种曲线救国的方法。

2）还有一种状况是，开始的时候你们Code Review都还挺认真，可是时间长了，你们以为这事跟KPI无关，并且我还要看别人的代码，理解业务，多浪费我时间啊。慢慢地就会发生这样的状况：有人提交了代码，随便抓我的Review，Review的人也不认真，随便扫一眼就点approve了。一旦发生破窗效应，Code Review也就会变成流于形式了。

个人对策是：一方面，要明确的告诉Code Review的重要性，要严格执行，让你们不要懈怠；另外一方面，是否能够间接的跟KPI，升职等联系在一块，senior的工程师有义务作Code Review，就像技术面试同样。再次，想办法活跃团队的技术氛围，把Code Review做为一种展现本身技术的机会，带动起你们Code Review的积极性，提升你们都Code Review的认同感（也算是洗脑吧）。

多说几句：Google的Code Review是作的很好的，能够说是谷歌保持代码高质量最有效的手段之一。Google的Code Review很是严格，多一个空行，多一个空格，注释有拼错的单词，变量命名的不够好，都被指出来要求修改。并且，全部的项目都要求Code Review。

欢迎留言区说说你对Code review的见解，大家公司是否有Code Review，在Code Review的过程当中遇到了哪些问题？