seo网站内容,建筑导航网站,实体店线上线下运营模式,iis 建立子网站Code Review#xff0c;在当代的软件开发中占有重要的一环。虽然国内各大主流公司都已经参照国外同行设立了比较严格的Code Review机制#xff0c;但是还是有好多大型软件公司以及中小型软件公司还未推行这一重要制度。那么在美国的科技企业中#xff0c;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美国科技公司让工程师进行轮岗以便线上代码出现问题时可以快速介入进行问题排查前一周就会选择性对某些比较大的PRPull 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. 如果觉得文章还不错欢迎点赞/分享/转发本文。如果你想加入号主的讨论群可以在公众号的关于我们-技术讨论群中找到微信群组。
