听我的！美国科技公司这样做Code Review

Code Review，在当代的软件开发中占有重要的一环。虽然国内各大主流公司都已经参照国外同行设立了比较严格的Code Review机制，但是还是有好多大型软件公司以及中小型软件公司还未推行这一重要制度。那么在美国的科技企业中，Code Review推行的怎么样呢？本文就带大家来进行一个全面的了解。本文将主要探讨如下几个部分，在公司内部推行Code Review的必要性，以美国某大型公司的内部工具进行具体Code Review流程讲解，作为CodeReview的双方应该在这一过程中注意什么。

Code Review的必要性

在一次完整的代码提交过程中，我们需要经过以下步骤

• 从主代码库中Check out出自己的分支

• 在自己的分支中进行代码修改

• 编写测试代码确保自己新增的代码逻辑不会破坏现有代码，以及新增代码被测试用例覆盖到

• 如果测试用例检测出代码逻辑问题，对代码进行修改

• 提交Code Review

• 在获得了审阅者通过后，并且通过了所有自动化测试用例，才可以将代码放置到生产环境代码库中 由此我们可以看出，Code Review是将代码提交代码库中的最终也是最重要的环节。没有这一环的保证，代码库中将充斥着大量低质量，甚至是错误的代码。

相对于国内公司大部分公司并没有全面推行Code Review，在美国，基本所有的非外包科技类公司都对这一环节进行了很好的推行，几乎每个开发团队每天都需要进行Code Review。以作者的了解，像Google、微软这类大型公司往往对Code Review的把控比较严格，至少需要两个同事通过，你的代码才可以提交到最终生产环境代码库中。如果某些修改的代码比较大，可能需要组里级别比较高的成员——比如资深工程师甚至是工程经理，通过才可以。有的修改如果牵涉到其他组的代码，还需要对应项目组的工程师通过才可以。那么既然Code Review是这么一件繁琐的事情，为什么各个公司还是不遗余力的推行呢。作者认为主要是以下方面使得这一环节在现代软件开发中十分必要。

• 有效的保证了代码风格的一致性 团队不需要再浪费时间去讨论个人喜好的代码风格，比如是用两个空格缩进还是四个空格，一行代码多长需要换行等等。编写代码的工程师只需要参照已有代码库中的编码风格即可，包括统一的命名规则，比如文件名和变量名，相似风格的代码注释。这一点其实对小公司更为重要，小公司相对大公司有更大的人员流动，从而更有可能出现各种风格的代码。另外，大公司内部工具相对完善，比如都会装有代码风格检查的工具，使得代码格式一致，而小公司可能需要更为严格的代码审查来保证这一点。

• 预防可能出现的Bug 编写程序并不是简单的体力劳动，那么在代码的创作过程中工程师难免会出现一些考虑不周的情况，比如某些未考虑到的边界情况，可能会造成代码在某些情况下崩溃，又或者是工程师在某些疲劳状态下写出的一些显而易见的错误。Code Review就是三个臭皮匠顶个诸葛亮的最佳诠释，在这一过程中发现代码中的错误。

• 相互讨论促进和谐友好的工程师氛围以及对代码库更完备的理解 在Code Review时，工程师之间并没有等级之分，即使你作为一个初级工程师，也可以给资深工程师审阅代码。作为被Review者，因为会和进行审阅的工程师不断沟通，从而对自己做的这一问题有了更深入的了解。有时，也会从资深工程师给出的代码评论中学到一些之前并不了解或者并不重视的技术细节，从而提高个人水平。而作为进行审阅的工程师，或许之前并没有接触过你代码的业务逻辑，通过审阅他也对这一领域有了了解。这一点非常重要，因为这可以帮助他在线上代码出现问题时，进行有效的排查。因为作者所在的公司每周一进行生产代码部署，所以我就会在Oncall（美国科技公司让工程师进行轮岗，以便线上代码出现问题时可以快速介入进行问题排查）前一周就会选择性对某些比较大的PR（Pull Request，指工程师将一系列文件修改提交到代码库中）进行Review，做到心中有数，一旦出现问题，可以找到对应的责任人对问题进行快速修复。

Code Review的流程

我们以某公司内部的Code Review工具来看看一次完整的Code Review过程是怎么样的。在该工具中A处表示这一次提交的代码所涉及到的全部被修改的文件。B处说明了这次代码修改的作者是谁(author)，哪些人是必须作为审阅者来审阅代码的（required），哪些审阅者是可选的（optional），对应审阅者是否通过代码，如果审阅者通过了你的代码，他的状态就会变成一个对勾符号。如果被标记为required的审阅者不通过，那么你的代码是不能进行最后的提交的。C表示作者做出的修改，图中红色部分为删除的代码，绿色部分为新增加的代码。D处是所有评论的概览，通过概览点击可以直接定位到评论对应的代码部分。E处是代码修改的次数，在作者第一次提交时被标记为1，当审阅者针对第一轮代码提出意见后，作者会对代码某些部分作出修改后再提交审阅。而每一次作者提交代码，上面对应的数字都会加1。当审阅者通过你的代码，你将代码提交到代码库中以后，那么这次Code Review也宣告结束，在数字旁边会标注完成（Completed）。F处是作者和审阅者交换意见的地方，比如审阅者Trevor提出了问题，那么作者Christian在其下方进行回复，如果Trevor觉得作者说的合理，那么审阅者就将评论状态设置为关闭（Closed），表示其对这一部分的异议已经消除。这一过程也是区分一个工程师是新手还是老手的过程，一个菜鸟工程师往往需要多达10几轮的Code Review，而一个老手往往在几轮之后就可以顺利将代码提交。

那么作为被review者和review者需要在Code Review中怎么做呢？

被Review者

工程师最好提前针对这次提交的代码设计跟进行Code Review的工程师进行讨论，确保自己的设计和思路没有偏离方向，否则后续需要进行好多修改。

在提交Code Review时，最好有一些文字进行解释，比如提交的代码解决了什么问题或者增加了什么功能，为了这些改进自己是怎么进行修改的，以及自己是怎么进行测试的。这样可以方便其他一些工程师主动参与进来，提出意见。

在自己的代码中尽量避免出现一些较为低级的，明显需要修改的代码。比如参照已有代码格式，命名等，确保自己的代码风格和已有代码是完全兼容的。

要对自己的代码有责任心，要确保自己了解做出的每一处修改，而不仅仅只是为了通过Code Review。不要过分依赖其他review代码的工程师，认为他们可以找出每一处潜在bug。

Review者进行Review的工程师在review别人代码时，尽量看到好的一面，这一点在给新人进行review时尤其重要。在给新人review时也是传授方法的好时候。授人以鱼不如授人以渔，当新人成长起来可以独挡一面，同时也减轻了你的工作量。

进行评论时要注意语气，尽量使用一些语气助词和Emoji符号表情，比如能否请你把XX改成XX？这里是不是用XX方法比较好。这样也更让对方易于接受。

积极主动参与Code Review可以让你对项目代码熟悉程度比较均衡，不会出现某个地方完全不了解的情况。而作为新人工程师，更需要积极参与Code Review，尤其尽量至少对每个组员的工作都进行review，这样也可以更为快速的了解组里其他工程师正在做的工作。

总结

本文通过美国某公司内部Code Review工具实例介绍了一次完整的Code Review是怎么样的，并对Code Review双方给出了建议。希望所在公司还没有推行Code Review机制的小伙伴能多多谏言推行，从而减少一些低质量代码带来的苦恼。

PS. 如果觉得文章还不错，欢迎点赞/分享/转发本文。如果你想加入号主的讨论群，可以在公众号的关于我们->技术讨论群中找到微信群组。