加餐三 | 聊一聊Google是如何做Code Review的

Jun 24, 2020

加餐三 | 聊一聊Google是如何做Code Review的-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

加餐三 | 聊一聊Google是如何做Code Review的

2020-06-24 王争来自北京

《设计模式之美》

课程介绍



讲述：冯永吉

时长09:36大小8.79M



100 篇的正文已经全部结束了，估计你学得也有点累了吧？时隔这么久，正文终于结束了，从今天起，我们继续加餐内容。
跟正文内容相比，加餐内容我希望尽量轻松有趣，帮你拓展知识面，主要是课后的一些小分享，有的会以讲故事为主，但我也希望它能给你带来收获。如果能够引发你的思考和共鸣那就更好了。所以，我也希望你在留言区，多说说自己的感受和看法，多多与我互动。
话不多说，让我们正式开始今天加餐的内容吧！
为什么国内企业不重视 Code Review？在专栏第 80 讲中，我列举了 Code Review 的重要性，在项目中执行 Code Review 会带来哪些好处，以及如何克服一些常见的难题，在项目中启动 Code Review 等等。今天，我们想再继续这个话题，和你聊一下 Code Review。不过，我刚才也说了，今天的内容会相对轻松一些，我会主要给你讲讲我在 Google 做 Code Review 的一些经验和心得。
我们都知道，Google 在 Code Review 方面做得非常好，可以说是很多公司学习的榜样。从我个人的经历来说，我的技术成长相当大的一部分得益于当年在 Google 的 Code Review。所以，我也希望更多的同行能意识到 Code Review 的重要性，能够在项目中推行 Code Review，受益于 Code Review。
但据我了解，国内的大部分公司都不怎么接受 Code Review，在开发中，根本没有 Code Review 的流程。所以，我一直思考，到底是什么原因，导致这么优秀的一种开发模式，在国内的技术圈内没有被发扬光大。很多人会认为，主要原因是，项目工期紧，没时间做 Code Review。我觉得这只是表面的原因，最根本的原因还是缺少技术文化传承。
我们知道，普遍而言，越是大公司里的工程师，技术能力会越强，技术影响力会越大。这些公司的工程师，即便跳槽去其他公司，一般都会担任核心成员或者 Leader 的角色。但是，在国内，即便像 BAT 这些输出有影响力工程师最多的一线公司，也没有很好地实践 Code Review，相对应的，这些公司的工程师也就没有一手的 Code Review 的经验和感受，更无法了解到 Code Review 的好处，也更不会在团队、公司，甚至技术圈中去推行 Code Review 了。
打个不恰当的比方，这些一线互联网公司的工程师一直接受着“996”狼性文化价值观的熏陶，即便跳槽去其他公司，作为资深员工或者技术 Leader，他们也会带领新的团队开始 996，最终导致整个 IT 行业的加班氛围都很浓，不加班反倒会显得不正常。
用 996 作类比，如果 BAT 这些比较有技术影响力的公司，内部对 Code Review 很认可，执行得非常好，从这些公司往外输出的工程师，就会像我一样，大力传播 Code Review。星星之火可以燎原，慢慢地，整个技术圈就会接受并且推行 Code Review 了。
实际上，据我所知，不只是我，只要是从 Google 跳槽出来的工程师，到了其他公司之后，都特别热衷于传播 Code Review。而且，只要是被 Google 工程师带领过的团队，在开发流程中严格执行过 Code Review 的团队，对 Code Review 都无比认可。所以，我个人觉得，很多人不认可、不推行 Code Review，最直接的原因还是没有经历过 Code Review，没有有经验的人来带。
实际上，才开始接触 Code Review 的时候，我也比较反感。我刚毕业就进入了 Google，在此之前，上学的时候，尽管也写了很多代码，也参与过一些垂直课题的研发，但是，那时候的开发只是为了完成功能，从来没有考虑过代码质量问题、代码设计问题，更别提 Code Review 了。现在想想，自己当时对 Code Review 的认知水平，跟现在很多国内工程师的认知其实是差不多的。
所以，在一开始进入 Google 的时候，对于 Code Review 我也是不怎么接受的。我第一次提交的代码不足百行，就被 Leader Review 出了 n 多问题，而且大部分问题都非常细节，比如变量的命名不够达意、注释不够规范、多了一个空行、少了一个空格之类的。对于这些琐碎的细节，我当时心里挺排斥的，心想：我是来“造火箭”的，为什么成天纠结于这些“拧螺丝”的事情呢？
现在回去想想，当时的想法真的挺幼稚的。
如果站在团队协作的角度来看，对于一个长期维护、多人参与、代码比较多的项目来说，代码的可读性、可维护性等与质量相关的问题，是非常重要的。所以，Code Review 作为保证代码质量的最有效手段之一，也就非常有必要了。如此吹毛求疵地执行 Code Review，看似非常极端，但也表明了公司强硬的态度、坚定的立场，就是要把 Code Review 执行彻底。这也是 Code Review 没有在 Google 流于形式的一个很大的原因。
在入职一段时间后，来来回回经过多次 Code Review 之后，我的代码质量整体提高了很多，被 Review 出的问题也越来越少了，我也切身地体会到 Code Review 的好处。因此，慢慢地，对这件事，我从排斥变得认可。与此同时，我也慢慢地开始 Review 别人的代码了。
Google 是如何进行 Code Review 的？在 Google，我们把每次提交的代码片段叫做一个 CL，全称是 Change List。它就相当于 GitHub 中的 PR（Pull Request）。每个 CL 都要至少一个 Owner 和一个具有 Readability 的同事 Approve，才能提交到代码仓库中。其中，Owner 一般都是技术 Leader 或者项目负责人，而 Readability 是一个证书，表示你具有了写出可读代码、符合编码规范代码的能力。Readability 会细化到每种编程语言，比如 Java Readability、C++ Readability 等。
如果你想申请某种语言的 Readability，你就要提交一段至少包含 100 行代码、并且稍微有点复杂的 CL 给 Readablity 评审委员会。评审委员会会指派一个资深工程师 Review 你的代码，给你一些修改建议，然后，你需要根据修改建议对代码进行修改，再提交 Review。这样来来回回几次之后，他觉得没问题了，就会给你颁发 Readability。有了 Readability 之后，你的 Review 才真的能起到 Approve 的作用。当然，即便没有 Readability，你对同事代码的 Review 本身也是有价值的。所以，并非只有 Readability 的人才能 Review 别人的代码。
在 Google，每种编程语言都有对应的编码规范。但是，Code Review 本身并没有统一的 Check list。在 Code Review 的时候，除了编码规范可以参考之外，大部分都是靠工程师自身的经验来 Review。不过，Review 考虑的也无外乎这样几个常见的方面：代码结构是否合理、代码是否容易理解、业务是否正确、异常考虑是否全面、是否有隐藏的 bug、线程是否安全、性能是否满足业务需求、是否符合编码规范等等。
Code Review 听起来很复杂，要考虑的点很多，但实际上，等到你做熟练了之后，并不会花费太长的时间。一个 CL 从提交 Review 到最终合并到代码仓库，一般也就需要一天的时间。当然，对于一些比较大的 CL、比较复杂的 CL、有比较多争议的 CL，以及一些新手的 CL，可能会花费比较多的时间。
但是，大部分情况下，我们都不提倡太大的 CL。太大的 CL 对代码审查者来说是很大的负担，Review 过程会很慢，会导致代码迟迟提交不上去。
对于比较复杂的 CL，我们一般建议要写好文档，或者通过类似 Jira 这样的项目工具，详细描述 CL 的前因后果、上下文背景。这样，代码审查者就能一眼看懂代码包含的设计意图。对于争议比较多的 CL，我们建议直接当面沟通，这样也更加有效率。对于一些新手的 CL，因为他们对编码规范等不熟练，可能来来回回要改好几次，才能满足要求，但这个过程是每个新人都要经历的，多改几次就好了。
实际上，Code Review 并不神秘，如果你想了解更多关于 Code Review 的事情，可以去读一读 Google 官方公布的Code Review 最佳实践。当然，如果有什么疑问，你也可以在留言区问我。
让国内大部分 IT 从业人士认识到 Code Review 的重要性，形成 Code Review 的技术文化，可能还需要一个漫长的时间。不过，我特别希望，你在学完专栏之后，能够意识到 Code Review 的重要性。有朝一日，当你成了领导，有了话语权、影响力之后，能够推动在团队、公司内进行 Code Review，甚至为 Code Review 在整个国内技术圈中发扬光大贡献一份力量。
课堂讨论你觉得为什么国内的大部分公司都不重视 Code Review，在开发中都没有 Code Review 流程呢？你觉得如何把 Code Review 在国内技术圈中发扬光大呢？有什么好的建议吗？
欢迎留言和我分享你的想法，如果有收获，也欢迎你把这篇文章分享给你的朋友。

分享给需要的人，Ta购买本课程，你将得29元

生成海报并分享

赞 49

提建议

春节特别加餐 | 王争：如何学习《设计模式之美》专栏？

加餐四 | 聊一聊Google那些让我快速成长的地方

 写留言

精选留言(58)

tingye
2020-06-24
国内code review难推广的一个原因可能也和文化有关，老外习惯直来直往评价和就事论事，中国人为人处世讲究委婉，要面子，特别同级别同事间往往不好意思直接指出别人的问题
作者回复: 说的太对了
共 10 条评论
117
Jxin
2020-06-24
原因： 1.缺少追求卓越的氛围。先run的理念退化成了能run就行。 2.招聘要求上基本都会有代码设计能力，编码规范，甚至代码洁癖的项。但实际上基本不提，顶多背几个设计模式。那么编码能力就变得很鸡肋，因为它与薪资几乎无关。叫好不叫坐大概就是这个意思。 3.重构本是小步快跑，但我看到的大部分都是重写，而非重构。这就导致认知中的重构成本很高，进而就会排斥。而只写代码不重构代码，在编码能力的提升上是很缓慢的。如果把识别坏代码的能力看作是一把尺子。经常重构的人，这把尺子的精度是一毫米，只写功能的人精度只有一分米。那么在识别坏味道评估改动点时就会很模糊，模糊就更不敢下手，恶性循环。办法： 1.氛围，国内的开源项目先开始讲究，带个氛围。 2.将编码能力和算法放在同等位置看待。其实编码能力强的人，往往意味着思路清晰，讲究。这种人工作能力一般差不了。 3.普及重构理应小步快跑的理念。把事情拆小，把小事情做好，都很重要。重构需要会拆解工作，然后也别看重构手法简单，刻意训练后也会有质变。（重构是提高普遍认知的有效手段，只有认知上去了codereview才能被重视）
展开
共 4 条评论
49
翠羽香凝
2020-07-04
我同时在美资外企和中国本土企业工作过，看到了另一个方面的问题：在美资企业，往往技术领导者有很大的权限，甚至很多公司的最高领导自己就是技术出身，对技术非常重视，也重视代码质量。而中国的本土企业，大部分公司的领导都是销售，财务出身，有些甚至来自投行，把PPT看得重于一切，至于代码质量，抱歉，领导可能重来不知道代码还有质量这回事，不是应该完成功能通过测试就OK了吗？而且，大部分的项目都很短命，就像中国的PPT文化一样，开发项目的目的就是“骗骗你”，钱到手了，项目的是否易于维护，是否易于扩展都并不重要，领导不关心，抱歉，你还真以为你要做一个Facebook呢？看看中国有几个BAT就知道了。
展开
共 2 条评论
42
progyoung
2020-06-24
就个人的工作经历来看，很多互联网公司程序员的职责就是完成业务，没有功能bug是第一位的需求，至于代码质量，在leader的眼中根本就不重要。而且一个需求提出之后，恨不得马上就能看到结果，发布上线。在这样的大环境之下，996盛行，code review就被认为是浪费时间，怎么能推行的开呢？
23
wkq2786130
2020-06-24
我刚开始也不理解code review ，直到有一天发现自己写的代码自己读不懂，然后开始优化，开始写注释，理清主要逻辑，开始分层，开始使用通俗易懂的命名，后来逐渐意识到code review的好处
18
皮特尔
2020-06-26
之前好像听池老师说过：极客时间团队是有Code Review的。感觉这件事主要还是看团队吧。
作者回复: 有很多团队说有，实际上算不上有。。走个过场而已。。
共 3 条评论
13
Monday
2020-06-29
公司让我等制定code review规范，并推广。 ps:现在公司情况：code review 各自（组）为政。我了解的几个组是只在乎功能正确性，不怎么在乎编码规范/风格、命名风格。各组的评审流程也不一样。我现在的思路 1、收集各组的评审方式及规范 2、整合各组的方式和规范结合业界的最佳实践（如google）制定出适合我司的一套规范与流程1.0 3、推广使用，收集反馈，补充和优化规范和流程，避免形式化小争哥或各位学友有哪些好的建议呢，谢谢
展开
作者回复: 不错，可以先把你列举的这些执行到位再说~
共 2 条评论
11
黄林晴
2020-06-29
最后一段说的很扎心等你当了领导有了话语权 …… 可能坚持review 的人由于让同事觉得太苛刻伤面子，永远很难晋升
8
焕伦蔡
2020-06-29
个人愚见，无法推行code review的原因： 1.很多公司项目本来也就做不大，大不了就费点时间重写呗，有些项目甚至就是做死了，例如Java来说可能一个SSM就搞定了，然后也就没有然后了 2.团队水平有限，团队没有一两个确实有能力的人，都不知道什么样的代码才是优秀的代码，code review就会变得很耗时费力，基本到后面就都没人做了解决方法： 1.看过《高效能程序员的修炼》一书，觉得有一点很好，那就是确保有多一双眼睛盯着你的代码 2.制定最简单基础的规范，比如说命名为驼峰，不能使用拼音，超过一屏的函数得拆分，然后强制执行，所有人按着这个标准，有时候简单暴力就是最有效的
展开
共 1 条评论
7
K战神
2020-06-29
有一次看到新人代码有很多问题时，我马上进行了提交限制权限。每一次提交的代码都发合并请求，我会每一句仔细看，然后评论，改完，再看再评论。效果显著，我们一起根据问题对应到代码整洁之道这本书，看看命中了拿着坑。还有一次我们同级别的审查我的代码，我当时确实比较排斥，我觉得同级别有经验的一起互相审核，感觉难度确实有些大，大家都在极力表述自己是对的，反而再互相理论。推行代码审查，前几步确实很费时间，很费精力，后面慢慢就好了，然后这种对代码的极致追求会成为习惯
展开
7
西门吹牛
2020-06-29
我们公司，从18年底就开始接入code review了，然后到现在，大家都把code review当成了一个过场，哎，那谁给我过下代码。个人感觉，code review带来的益处是需要个长期积累的过程，短时间，对个人，对公司来说，带来的益处也许并不明显。但是坚持下去，时间一久，就会得到意外的收获。code review更加是一种态度，一种责任
5
程序员小跃
2020-10-21
比较庆幸自己的第一份真正意义上的工作就有Code Review的存在，让我从菜鸟开始就体会到了Code Review的重要性。当别人监督你的时候，你自然就会给自己绷紧一根筋，刻意需要自己严格按照公司的规范写代码。可惜后来出圈了，氛围变了，尽管自己刻意练习，但还是不免有松懈的地方。如何破圈？我估计，就是让我更努力点，先成为Leader吧，哈哈
展开
3
微末凡尘
2020-07-02
以前写代码从来没有注意代码质量的问题，而是完成功能为第一步，然后就没有然后了，直到我现在入职一家新公司，虽然公司不大，但是有很好的CR习惯，每次提交代码，leader都会review我的代码并且非常细心，耐心的给出修改意见，有助于我代码水平的提高，现在写代码时会不自觉地注意代码书写的规范，因为感觉总有一双眼睛盯着你在。。。
3
黄骏
2020-06-26
有时候review同事的pr，一些语法和编程风格的问题比较多，好像重视程度也不够，反馈后新的pr仍然如此，对reviewer来说就不太友好了，觉得我提的问题太傻了么？
作者回复: 反馈给领导层，让领导层推编程规范~
3
迷羊
2020-06-24
感觉还是没有会 Code Review 的人带
作者回复: 杨哥，我带你！
共 6 条评论
3
Jackey
2020-06-24
能做的就是在自己的团队中大力推广code review，不符合规范的代码一定不能进入repo
3
djfhchdh
2020-09-10
codeReview和kpi、绩效又不挂钩，老板只关注结果，所以注定cr推行只能流于形式。
2
coco張
2020-07-03
我们公司也有code review,外企嘛，很多形式都会有的，但是效果不是特别好，关键还是reviewer的能力不足以支撑给出意见，流程上是加上了，但是merge以后还是一改再改
2
全炸攻城狮
2020-07-01
code review的前提是知道什么是好代码，以及严格的编码规范。第一点需要有经验的工程师，具备review其他人代码能力的leader，第二点需要借助工具如lint。还有一点是要形成习惯，当成开发任务中的正常环节就好了
2
cricket1981
2020-06-27
想了解下Google是如何将这些规范落地的？有什么具体措施国内公司能够借鉴吗？道理大家都懂，但实际操作起来怎么监督实施呢？
作者回复: 对于不满足规范的，坚决不让提交上去。就看有么有决心执行了。
2

