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

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

王争 2020-06-24

104 - 图1



00:00

1.0x

讲述：冯永吉大小：8.79M时长：09:35

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 在国内技术圈中发扬光大呢？有什么好的建议吗？

欢迎留言和我分享你的想法，如果有收获，也欢迎你把这篇文章分享给你的朋友。

32人觉得很赞给文章提建议;)

104 - 图2

104 - 图3

张创琦

Ctrl + Enter 发表

0/2000字

提交留言

精选留言(53)

tingye
国内code review难推广的一个原因可能也和文化有关，老外习惯直来直往评价和就事论事，中国人为人处世讲究委婉，要面子，特别同级别同事间往往不好意思直接指出别人的问题
作者回复: 说的太对了
2020-06-24
_9
_91
Jxin
原因：
1.缺少追求卓越的氛围。先run的理念退化成了能run就行。
2.招聘要求上基本都会有代码设计能力，编码规范，甚至代码洁癖的项。但实际上基本不提，顶多背几个设计模式。那么编码能力就变得很鸡肋，因为它与薪资几乎无关。叫好不叫坐大概就是这个意思。
3.重构本是小步快跑，但我看到的大部分都是重写，而非重构。这就导致认知中的重构成本很高，进而就会排斥。而只写代码不重构代码，在编码能力的提升上是很缓慢的。如果把识别坏代码的能力看作是一把尺子。经常重构的人，这把尺子的精度是一毫米，只写功能的人精度只有一分米。那么在识别坏味道评估改动点时就会很模糊，模糊就更不敢下手，恶性循环。
办法：
1.氛围，国内的开源项目先开始讲究，带个氛围。
2.将编码能力和算法放在同等位置看待。其实编码能力强的人，往往意味着思路清晰，讲究。这种人工作能力一般差不了。
3.普及重构理应小步快跑的理念。把事情拆小，把小事情做好，都很重要。重构需要会拆解工作，然后也别看重构手法简单，刻意训练后也会有质变。（重构是提高普遍认知的有效手段，只有认知上去了codereview才能被重视）
2020-06-24
_4
_34
翠羽香凝
我同时在美资外企和中国本土企业工作过，看到了另一个方面的问题：在美资企业，往往技术领导者有很大的权限，甚至很多公司的最高领导自己就是技术出身，对技术非常重视，也重视代码质量。
而中国的本土企业，大部分公司的领导都是销售，财务出身，有些甚至来自投行，把PPT看得重于一切，至于代码质量，抱歉，领导可能重来不知道代码还有质量这回事，不是应该完成功能通过测试就OK了吗？
而且，大部分的项目都很短命，就像中国的PPT文化一样，开发项目的目的就是“骗骗你”，钱到手了，项目的是否易于维护，是否易于扩展都并不重要，领导不关心，抱歉，你还真以为你要做一个Facebook呢？看看中国有几个BAT就知道了。
2020-07-04
_1
_31
progyoung
就个人的工作经历来看，很多互联网公司程序员的职责就是完成业务，没有功能bug是第一位的需求，至于代码质量，在leader的眼中根本就不重要。而且一个需求提出之后，恨不得马上就能看到结果，发布上线。在这样的大环境之下，996盛行，code review就被认为是浪费时间，怎么能推行的开呢？
2020-06-24

__20
wkq2786130
我刚开始也不理解code review ，直到有一天发现自己写的代码自己读不懂，然后开始优化，开始写注释，理清主要逻辑，开始分层，开始使用通俗易懂的命名，后来逐渐意识到code review的好处
2020-06-24

__16
皮特尔
之前好像听池老师说过：极客时间团队是有Code Review的。
感觉这件事主要还是看团队吧。
作者回复: 有很多团队说有，实际上算不上有。。走个过场而已。。
2020-06-26
_2
_13
Monday
公司让我等制定code review规范，并推广。
ps:现在公司情况：code review 各自（组）为政。
我了解的几个组是只在乎功能正确性，不怎么在乎编码规范/风格、命名风格。各组的评审流程也不一样。
我现在的思路
1、收集各组的评审方式及规范
2、整合各组的方式和规范结合业界的最佳实践（如google）制定出适合我司的一套规范与流程1.0
3、推广使用，收集反馈，补充和优化规范和流程，避免形式化
小争哥或各位学友有哪些好的建议呢，谢谢
作者回复: 不错，可以先把你列举的这些执行到位再说~
2020-06-29
_1
_11
黄林晴
最后一段说的很扎心
等你当了领导有了话语权 ……
可能坚持review 的人由于让同事觉得太苛刻
伤面子，永远很难晋升
2020-06-29

__7
焕伦蔡
个人愚见，无法推行code review的原因：
1.很多公司项目本来也就做不大，大不了就费点时间重写呗，有些项目甚至就是做死了，例如Java来说可能一个SSM就搞定了，然后也就没有然后了
2.团队水平有限，团队没有一两个确实有能力的人，都不知道什么样的代码才是优秀的代码，code review就会变得很耗时费力，基本到后面就都没人做了
解决方法：
1.看过《高效能程序员的修炼》一书，觉得有一点很好，那就是确保有多一双眼睛盯着你的代码
2.制定最简单基础的规范，比如说命名为驼峰，不能使用拼音，超过一屏的函数得拆分，然后强制执行，所有人按着这个标准，有时候简单暴力就是最有效的
2020-06-29
_1
_6
K战神
有一次看到新人代码有很多问题时，我马上进行了提交限制权限。每一次提交的代码都发合并请求，我会每一句仔细看，然后评论，改完，再看再评论。效果显著，我们一起根据问题对应到代码整洁之道这本书，看看命中了拿着坑。
还有一次我们同级别的审查我的代码，我当时确实比较排斥，我觉得同级别有经验的一起互相审核，感觉难度确实有些大，大家都在极力表述自己是对的，反而再互相理论。
推行代码审查，前几步确实很费时间，很费精力，后面慢慢就好了，然后这种对代码的极致追求会成为习惯
2020-06-29

__5
西门吹牛
我们公司，从18年底就开始接入code review了，然后到现在，大家都把code review当成了一个过场，哎，那谁给我过下代码。个人感觉，code review带来的益处是需要个长期积累的过程，短时间，对个人，对公司来说，带来的益处也许并不明显。但是坚持下去，时间一久，就会得到意外的收获。code review更加是一种态度，一种责任
2020-06-29

__4
微末凡尘
以前写代码从来没有注意代码质量的问题，而是完成功能为第一步，然后就没有然后了，直到我现在入职一家新公司，虽然公司不大，但是有很好的CR习惯，每次提交代码，leader都会review我的代码并且非常细心，耐心的给出修改意见，有助于我代码水平的提高，现在写代码时会不自觉地注意代码书写的规范，因为感觉总有一双眼睛盯着你在。。。
2020-07-02

__3
迷羊
感觉还是没有会 Code Review 的人带
作者回复: 杨哥，我带你！
2020-06-24
_5
_3
Jackey
能做的就是在自己的团队中大力推广code review，不符合规范的代码一定不能进入repo
2020-06-24

__3
程序员小跃
比较庆幸自己的第一份真正意义上的工作就有Code Review的存在，让我从菜鸟开始就体会到了Code Review的重要性。当别人监督你的时候，你自然就会给自己绷紧一根筋，刻意需要自己严格按照公司的规范写代码。
可惜后来出圈了，氛围变了，尽管自己刻意练习，但还是不免有松懈的地方。如何破圈？我估计，就是让我更努力点，先成为Leader吧，哈哈
2020-10-21

__2
djfhchdh
codeReview和kpi、绩效又不挂钩，老板只关注结果，所以注定cr推行只能流于形式。
2020-09-10

__2
全炸攻城狮
code review的前提是知道什么是好代码，以及严格的编码规范。第一点需要有经验的工程师，具备review其他人代码能力的leader，第二点需要借助工具如lint。还有一点是要形成习惯，当成开发任务中的正常环节就好了
2020-07-01

__2
cricket1981
想了解下Google是如何将这些规范落地的？有什么具体措施国内公司能够借鉴吗？道理大家都懂，但实际操作起来怎么监督实施呢？
作者回复: 对于不满足规范的，坚决不让提交上去。就看有么有决心执行了。
2020-06-27

__2
黄骏
有时候review同事的pr，一些语法和编程风格的问题比较多，好像重视程度也不够，反馈后新的pr仍然如此，对reviewer来说就不太友好了，觉得我提的问题太傻了么？
作者回复: 反馈给领导层，让领导层推编程规范~
2020-06-26

__2
虢國技醬
我觉得code review好处之一就是帮助部分同学提高编码技能；毕竟工作不像在学校，写的不好的同学老师会手把手教你，code review让大家看到优秀的，也看到槽糕的
2020-06-24

__2
朱月俊
我认为有两个原因吧，至于”碍于面子”这种解释有一点站不住脚。
原因一，国内做事比较急躁，只做跟kpi或者okr有直接关系的事，而cr表面上还是阻止功能上线的一个拦路虎，甚至怀疑同事会故意找麻烦，第一印象认为别人是坏的。我印象，脸书有一个价值观，think good.
原因二，老大们只关心业务价值，并且一个团队的寿命比较短，可能3年左右就大换血，老大们才不会去做没有长久的事情。
2020-07-19

__1
coco張
我们公司也有code review,外企嘛，很多形式都会有的，但是效果不是特别好，关键还是reviewer的能力不足以支撑给出意见，流程上是加上了，但是merge以后还是一改再改
2020-07-03

__1
丹枫无迹
确实，最主要的问题是没有会 Code Review 的人带，不知道怎么去开展。如果完全靠自己摸索，那进展就会缓慢，迟迟不出效果，即便老板一开始是支持的，后面也会开始怀疑，最后可能就是不了了之。
2020-06-29

__1
Michael
我司这方面做的还可以
2020-06-26

__1
silent
国内互联网公司，所有人时间都很紧张，没有时间做cr。当然，根本原因是不重视，毕竟谁代码不行裁掉换一个就好了，不用花时间帮助他提升自己。本质上还是把人当人肉干电池用hhh
2020-06-26

__1
南山
现在所在的团队不做cr，不准提测，也一直在强调cr的重要性，做cr的时候也很认真，挺好，以后自己有话语权一样这么干~
2020-06-25

__1
liuliu
\1. 没有切身体验到 code review 的好处，大多是流于形式的过一遍，或者根本没有。
\2. 觉得是种负担，浪费时间。没有把它作为一种可以提高代码质量，发现隐藏问题的方式。
\3. 目前我们的 code review 也只是检查些较明显出错的地方，并不细致。
\4. 需要对 code review 有丰富经验的人从小范围开始推广，并见到实效，进而逐步铺开。
2020-06-24

_1
dexia
欧美可以靠着系统专利的垄断带来高利润，使得他们就不用像国人那样拼命，这就是先发国家的优势，短时间无法撼动（所以google的CodeReview进行得那么顺利），而我国就只得靠拼命努力去抢夺市场争取那丁点儿的利润，就像是处在社会底层的阶层人民竞争越是激烈，资源就那么点儿，没有办法
2021-10-13


cv0cv0
然而Code Review并不能让Android变得好用。
2021-09-27


Leoorz
不真正以“坚持做长期而正确的事”为绩效导向的地方，举措再详细，最终也就是走个过场
2021-09-09


David
前辈可以开个业务，就是让我们这些没经过code review训练的人向您提交代码，让我们也可以亲身体会一下。
2021-08-25


李二狗
国内应该是少经验，没氛围
2021-07-01


青年祭司
Code Review对新手肯定是有好处的，对leader有什么好处呢
2021-06-23


Deabel
因为事不关己高高挂起。公司没有有效的相关奖惩制度，很难推行。
2021-05-17


yang
因为一直在甲方，所以没有code review的经验。但可以看出我们的乙方的code review很差。之前有一段时间总有莫名其妙的bug,他们一排查至少好几天，我很崩溃。很多需求其实和之前的功能没有本质区别，但他们要么不能实现，要么需要好几个月才实现，除了改进意愿不够之外，至少还说明他们的代码结构不好。我觉得如果甲方对代码质量有具体要求的话，code review会更发扬光大吧～～
2021-05-05


皮邱～
主要还是不会code review的人水平不够，比如让我去review，除了特别烂的代码我能指指点点，否则我说不出啥来
2021-05-04


williamcai
好多做项目，追求快蒙操，根本没时间进行code riview。我认为应该在流程上进行规范
2021-04-26


流沙
我觉得是违法成本低前提下劣币驱逐良币的结果。大搞996，没有工程师文化的企业，在市场上取得了成功；将追求精益求精的企业逐出市场
2021-02-22


小音者
这里字节跳动前端，我司难以推行 Code Review 的问题是缺乏代码规范，导致 Review 没有标的。实际上国内React/Vue技术栈的前端开发几乎是没有任何代码规范的，社区“状态管理”方案百花齐放，沿用了古老的项目级MV*分层，而不是DDD设计。并且缺乏依赖注入框架，更是还有很多老旧的JS而非TS代码。所以Code Review需要一个前提是有一个通用的编码规范。然而国内前端几乎没有能够设计可以满足业务需求的通用规范的人才。。
2021-01-28


long
咨询一个问题，是在dev分支还是feature分支做，如过在开发分支做，是不是因为每天提交的过于频繁，并且缺乏逻辑整体性，导致cr效果不理想。
2021-01-21


Next
1、不好意思说明别人的问题
2、代码质量意识不高
2020-12-24


色即是空
工期紧，任务重，时间不够；
2020-10-29


赵学习
Code Review 走过的过场实在是形式化太严重了。
2020-10-18


prozac
我是今年暑假阿里的一个实习生，刚来阿里的时候发现部门没有CR文化，于是做了一些调研并且在征得主管同意的情况下在周会上和大家讨论了CR制度推行的事，发现之前CR没推行的一个很重要的原因就是有的人不喜欢，当然这个也和CR的执行策略有关，我主管说之前有个人在被当众CR的时候哭了出来。这次会议的结果是我们部门开始推行核心代码的CR流程，但是作为实习生的我实习到结束也没有参与到这个过程中…
2020-09-21


忆水寒
国内主要是，新人不敢质疑老员工，低级的不敢质疑高级的工程师写的有问题。毕竟感觉会得罪人，不好混
2020-08-23
_1
_
makermade
前期。必须自顶而下强制推行
2020-08-10


hello
我们团队每次代码几乎都会code review，但是由于开发时间不够，review的问题改或不改都能提交。。。
2020-07-15


aoe
\1. 你觉得为什么国内的大部分公司都不重视 Code Review，在开发中都没有 Code Review 流程呢？
因为大部分公司代码生命周期不会很长，有可能项目上线不到1年，公司就跑路了或者项目黄了，之前代码没用了。速度上线、圈钱才是重要的。
\2. 你觉得如何把 Code Review 在国内技术圈中发扬光大呢？
可以开个类似极客时间《算法训练营》的班，针对不同语言，由具有Code Review能力的老师培养大家。
当学员出师后，可能带来裂变效应。
\3. 有什么好的建议吗？
创建自己的公司，足够强大后，分享成功经验，期中重要的一条就是Code Review
2020-07-13


静静聆听
老师，我看了google的code review最佳实践，发现是以每一次的pull request为维度进行的code review，而我们现在的code review是以项目为维度的，项目提测前进行统一的code review，发现不好的代码，leader让去修改，这样两种方式哪种更好点啊
作者回复: 肯定是前一种了，后一种很难做全面细致吧
2020-07-08


Jem
code review 在17年接触到的，当时写的代码也是什么都没考虑，只要能运行就行。当我第一次提交代码时，说了我代码很多问题，当时我觉得为什么要在意这么多小细节，leader是不是故意刁难我，在一次次的code review中，渐渐的我的思想被改变了，发现以前写的代码是如此的粗糙，让我明白写代码不仅仅是有手就行，感谢当年给我带来code review思想的导师。
2020-07-07


守拙
个人对于”国内公司不重视, 不执行CR”的核心原因有不同见解:
国内无法推行Code Review的根本原因在于资本家的短视. 资本认为Code Review无法创造收益, 所以不重视.
马克思说过: 经济基础决定上层建筑.
作为上层建筑的Code Review需要经济基础的支持. 国内中小企业光是活下来就已经竭尽全力了, 哪有余力做Code Review之类锦上添花的事情呢.
当然个人非常希望我所在的团队能够执行Code Review. (我对自己的代码质量有信心, 更希望能有所精进)
但目前看来, Code Review更像是”遥远的理想乡”.
2020-06-24


可达鸭
- 心想：我是来“造火箭”的，为什么成天纠结于这些“拧螺丝”的事情呢？
哈哈大神的心路历程分享，着实有趣！
我们的老祖先早就说过：不积跬步无以至千里，细节决定成败！
把每件小事做好，那么大事当然也不在话下！学习如此，工作如此，做人也是如此！受教啦！
2020-06-24


沁塵
还有一个原因就是现在很多开发者本身就对自己的代码质量没有要求，能跑就行了。我觉得现在的开发者大致可以分为两类人，一种是热爱且用于安身立命。一种是混口饭吃而已。在国内这种就业环境和市场环境，后者肯定是多数，这群人也是最不会在意什么代码质量的，code review？听都没听过。
2020-06-24