Code Review 代码审查最佳实践 - 网站源码_资源分享

Code Review，英文叫标识符审查，指的是顺利完成了部分机能的标识符开发之后，在标识符真正合并到仓库主分支以后，邀请同事帮你展开标识符的审查和检查和，检查和标识符的产品质量、规范化、结构设计之类方面的操作过程。

标识符审查的益处

知识共享资源

展开标识符审查的益处许多，其中两个就是能让工程项目组的整体水准快速得到提高。两个工程项目组中有现职的工程师也有刚毕业的人，水准良莠不齐。

对刚进入工程项目组的人而言，不熟识许多工程项目组的规范化，所以就能通过标识符审查的操作过程展开辅导和分享。

如果控制系统间十分复杂，互相间的依赖初始化许多，一次标识符的修改可能会影响其他控制系统的运行，这时候，如果有比较熟识那个控制系统的人的提醒和辅导就能及时处理难题。

后辈能在那个操作过程中学到控制系统结构设计的原则，如何编写时效性和F83E43Se科灰藓的标识符，学习到控制研究课题最差课堂教学之类。工程项目组的水准因此而得以提高。

对工程项目组中的现职人士而言，他们可能觉得帮助后辈会节约他们的天数，只不过不然。当整个工程项目组更加杰出，水准更高，就能帮忙分摊更多重要的各项任务，而他们也能脱身去化解梅西县的难题或者展开自我提高。

工程项目组的沟通潜能越强、结构设计潜能越好只不过也是节省了他们的天数。谁不希望能高效地和别人密切合作顺利完成各项任务呢？与其低水准地交流密切合作，事情还暂时顺利完成不了，不如资金投入一些天数提高工程项目组的战力。

更好的标识符产品质量

许多公司工程项目组不著重标识符产品质量，认为工作顺利完成了，机能上架了就能了。只不过大家没有看到应用软件的开发周期中，生产成本最轻的两个环节就是持续的维护和更新插值。

标识符产品质量差，是将来无力偿还的技术债。标识符自如地写，每一人有每一人的偏好，没有任何规范化，也不著重时效性。虽然控制系统表面上化解了当下的难题，但当工程项目组成员流动，后辈接掌工程项目后，发现读要学，标识符如“屎”山，工程项目推翻重做，以后的资金投入continues。那个选人生产成本是否有考虑过？

举个简单的例子，就像建造两个平房，为了保证质量不著重工程产品质量，新房子外形是符合交付标准了，但新房子内部的东西以次充好，平房的寿命没过多久就变成危房，无法使用了，造成了大量的人力和资源的节约。

开放源码应用软件对标识符的审查十分严苛，这也是为什么开放源码应用软件的产品质量所以高以及能够历久不衰。开放源码工程项目的委员会会十分严苛地审查每一行标识符。良好的结构设计和杰出的标识符产品质量才得以让开放源码应用软件保持稳定的插值，以及持久的生命力。

标识符审查的目的

标识符审查有诸多的益处，而它的目的就是要引入工程项目组协作规范化，让所有贡献标识符的人都能够按照一定的流程和约定来顺利完成开发各项任务。

许多公司的标识符审查流于形式，只是走个过场，虽然需要别人同意才能够把标识符合并进主分支，但没有人对标识符展开严苛的考核，标识符风格也没有统一的约束。

有些人对标识符审查比较反感，认为是一种拖慢进度的强制流程。然而据我观察，对那些能够真正运用好标识符审查的公司，这对员工而言是一种福音，更像是大家共同建设的一种工程师文化。

因为对个人而言，能快速地学习和提高，对公司而言，应用软件的产品质量得到了保证，是一种双赢的举措。

标识符审查的心态

良好的标识符审查，少不了人和人间建立起的良好氛围，如谦逊，友善，互信互助和成长型心态。

作为审查别人标识符的人，需要就事论事，评论的语气要尊重他人，客观公正，带着帮助别人的心态去顺利完成审查。不要带有主观色彩，也不要有针对个人的行为。

作为提交标识符的人，不要害怕被别人发现他们的短板，不要对他们做得不好的地方遮遮掩掩。带着成长型的心态，发现难题就去化解，不会的东西就去学，虚心请教和学习，收起玻璃心，一切以成长为目的。

一旦工程项目组建立起良好的学习氛围，标识符审查的机制会朝着正循环滚动。

标识符审查的经验技巧

讲述了以上诸多的背景，来到正题，在国外大厂里，code review到底是怎么做的呢？

清晰的开发辅导

首先将工程项目组要求、开发经验整理成一份清晰的开发指引，让后辈通过阅读文档就能够知道应该怎么做，让工程项目组成员能够步伐一致比如写单元测试的要求，标识符风格如何统一，命名规范化，异常信息如何写之类杰出示例: [1].Contributing to Apache Spark

自我检查和

提交标识符前，先他们对照开发辅导展开检查和，避免PR(合并请求)被反复打回，减少不必要的天数节约他们检查和和发现一些低级的难题，这也是对别人天数的尊重

PR要足够小

尽量保证每次code review的标识符量在100行左右。太长的标识符变化会让查看的人看起来很费劲机能变化较大的改动，也能尽量拆分成若干个子各项任务或者模块，并在PR中描述清楚分别在实现哪个模块PR足够小，对双方而言都是双赢，审查标识符的人能够看得更快速，而提交标识符的人，能让标识符更快地合并到主分支

详细的上下文描述

有些人提交code review，什么也不说，就一段标识符给到审查的人，想当然地觉得别人什么都知道，应该知道他要实现的机能和达到的目的。

只不过作为提交者，应该站在对方的角度思考，假设对方对他们的实施操作过程一点都不了解，应该怎么提供更加详细的信息。

提供尽可能详细的前因后果。为什么要做这次改动，实现的目的是什么，是否有结构设计文档的链接，是否还有额外的参考文档，所有的信息都能整理清楚写到描述框中如果你的标识符只是实现了部分的机能，也要具体说明实现了哪一部分还能在讨论区指出，他们为什么这样实现。虽然标识符说明了一切，但一些额外的描述，能让对方更加容易理解，降低沟通的生产成本如果他们对某些标识符存有疑虑，也能指出并讨论，说明这不是最终的方案，还有待斟酌等

以上的目的，都是为了让对方更好理解他们的目的，详细的文档也为了以后再翻阅提供便利。

快速回应评论，关闭已化解的难题

主分支，会导致你需要不断地同步他们的标识符，化解标识符冲突，造成天数的节约另一方面，天数长了，又要去回忆当时的一些讨论，会导致标识符暂时无法合并已经化解的难题，能点击”Resolve“，让整个review的操作过程更加清晰，也知道他们的标识符进度如何

找到正确的人帮你审查

在两个大型的应用软件中，模块十分多，有些人特别熟识某些模块，应该找到对应的负责人来协助你审查标识符

如何审查别人的标识符

控制系统结构设计

从控制系统和站在组织的角度，问以下难题：

从控制系统的角度，这份标识符的改动会引起兼容性的难题吗？它能够很好地跟其他控制系统整合吗？该标识符的改动会不会引起控制系统故障或者影响其他依赖的控制系统的使用？现在是改变那个机能的恰当时机吗？整体的标识符是否符合逻辑？

机能性

从机能性的角度考察：

标识符是否能够实现开发者想要的目标？这份标识符是否包含测试？这些测试覆盖的场景是否足够多？是否考虑到了一些边界情况？并发的情况下性能怎么样，会不会产生死锁等难题？把他们想象成两个用户的角度，机能是否满足，是否考虑全面，是否存在一些bug？

标识符风格和命名规范化

这些标识符的命名是否规范化？如果让两个不太熟识的人来看这份标识符，是否能够通过命名就了解其含义？标识符有没有遵守约定的代码风格？比如 [2].Google Java style guides提交的标识符如果想要做一些标识符格式化的调整，如缩进和换行之类，需要放到另外的PR中展开，避免跟机能标识符混在一起，给阅读标识符的人造成不便。

测试

如果标识符中没有包含测试，要求开发者再附上完善的单元测试。原则上，每次标识符改动都应该有其对应的单元测试。确保测试是正确的，合理且有意义的以及能够尽可能覆盖足够多的情况。

文档

检查和是否需要更新相应的文档。比如一次大的修改，需要记录一些release note或者README。或者一些必要的注释放到标识符中，以备后续查阅。删除掉不必要的注释以及已弃用的标识符等。

以上只是摘录了部分比较主要的review流程，如果想要了解更多的细节，能到 [3].What to look for in code review 查阅。

Code Review 黑话

Code Review操作过程中有一些常见的缩写/术语，列出来以备不时之需~

LGTM: Looks good to me. 这句话通常代表标识符能合并了。PR: Pull request「合并请求」，有些地方也叫 Merge Request(MR).NIT: nitpick. 意思是有点吹毛求疵，不是十分重要，常指一些标识符风格的难题。WIP: Work In Progress. 意思是标识符还没有完全好，还在展开中，但能先整体看一下。TL;DR: Too Long; Didnt Read 「太长懒得看」，README 文档常见a.k.a.: also known as 「又称作」，比如 GitHub (a.k.a. GayHub) 。聊天消息里更常见到。RFC: Request for comments 「请求意见稿」