当前位置: 首页 > 科技观察

你厉害到CodeReview都不知道?

时间:2023-03-14 15:11:40 科技观察

我一直认为CodeReview(代码审查)是软件开发中的最佳实践之一,可以有效提高整体代码质量,及时发现代码中可能存在的问题。图片来自Unsplash,包括谷歌和微软等公司。CodeReview是一项基本要求。在合并代码之前,必须有人对其进行审查。但是,我观察过的大部分软件开发团队,很少有人认真做CodeReview,有的流于形式,有的可能根本就没有CodeReview,代码质量只靠事后测试。也有团队想做好codereview,但是不知道如何做得更好。网上已经有很多关于如何做CodeReview的文章。这里我结合自己的一些经验,总结一下CodeReview的优秀实践。希望对大家做好CodeReview有所帮助。CodeReview有什么好处?许多团队或个人不进行代码审查。根本原因是他们还是觉得这不是什么有意义的事情,觉得没有什么好处。这个问题应该从几个角度来看。从团队知识共享的角度来看在一个开发团队中,级别有高有低,每个人的侧重点也不一样:高级别如何帮助新人成长?每个人如何才能跟上他们关注领域之外的知识?有人离开后,其他人能否迅速接手?这些都是团队管理者关心的问题。代码审查是分享知识的好方法。通过代码审查,专家可以直接指出新手代码中存在的问题,新手可以立即从专家的反馈中学习到好的做法,实现更快的成长;通过codereview,前端也可以学习到后端的代码,让功能模块A可以学习到功能模块B。有的高手可能会觉得给新手review代码很浪费时间,一无所获。其实,新人长大后,可以帮助高手分担更重的任务;花在codereview上的时间会节省新人填坑擦屁股的时间。良好的沟通能力、发现问题的能力、帮助他人成长的能力,都是将技术转化为管理或将技术提升到更高水平的必备技能,而代码审查可以有效地练习这些技能。从代码质量角度看实际项目中,总是人手不足,工期紧,压缩的往往是自动化测试和代码审查,影响代码质量,欠下技术债,必须加倍结尾。也有人寄希望于开发后的人工测试。但是对于代码质量来说,很多问题是无法通过测试发现的,只能通过codereview才能通过。比如代码的可读性和可维护性,比如代码的结构,比如某些条件触发的死循环,逻辑算法错误,还有一些安全漏洞,通过codereview更容易发现和预防。有些人认为自己水平高了就不需要codereview了。对于专家来说,让别人审查自己的代码可以让别人学习好的做法;在让别人review的同时,在给别人解释自己的代码的时候,也相当于在review自己的代码。这其实和我们上学的时候做数学题是一样的。真正能拿高分的,往往是做完后会仔细检查的人。从团队规范来看,每个团队都有自己的代码规范,也有自己基于架构设计的开发规范。但是,随着时间的推移,你会发现代码中有很多不符合代码规范的情况,也有很多绕过架构设计的情况。代码。比如难以理解和不规则的命名,比如三层架构中的UI层绕过业务逻辑层,直接调用数据访问层代码。如果这些违反规范的代码改得晚了,后期修改成本会非常高,团队的规范也会逐渐变得无用。通过codereview,可以及时发现并纠正这些问题,保证团队规范的执行。关于codereview的好处,还有很多,就不一一列举了。我还是希望认识到,CodeReview和写自动化测试一样,是磨刀霍霍的活儿。如果您在其中投入一点时间,您将在未来获得代码质量并节省整体开发时间。如何进行代码审查?现在很多人已经意识到CodeReview的重要性,但是就是不知道怎么去实践,不知道怎样才能做好CodeReview实践。①将CodeReview作为开发过程的必经之路,而不是可选项。很久以前,我尝试将代码审查作为代码流程的一部分,但这只是一个选项。代码也可以在没有CodeReview的情况下合并到Master中。这样做的结果是,您只有在想到它时才进行CodeReview。去查的时候代码改动已经太多了,review难度很大。另外,即使review有问题,也很难修改。图片来源:如何像Huma一样进行代码审查我们当前的代码审查是开发过程中必不可少的。每次开发一个新特性或者修复一个bug,都会开辟一个新的分支,有两个分支要合并到MasterPrerequisites:自动化测试全部通过。至少有一个人通过了CodeReview。如果是新手PR,肯定有通过CodeReview的资深程序员。这样,在将CodeReview作为开发过程中的必选选项之后,就很好的保证了代码在合并前进行了CodeReview。而这种在合并前要求codereview的流程好处也很明显:由于每次合并前都需要codereview,所以一般来说审查的代码量不会太大,reviewer的压力也不会太大。如果在CodeReview的时候发现问题,被review的人希望代码能尽快合并,并且会积极修改review发现的问题,以免和review的结果矛盾太大。如果你觉得CodeReview很难实现,不妨尝试让CodeReview成为你开发过程中的必经之路。②把CodeReview变成一种开发文化而不仅仅是一个系统CodeReview在开发过程中是必须的之后,并不代表CodeReview可以很好的实施,因为CodeReview的实施非常重要。一定程度上取决于审稿人的细心审稿和被审稿人的积极配合,两者缺一不可!如果仅仅把它看成一个流程体系,那么它可能流于形式。最后的结果就是好像有CodeReview,但是没有人认真审查,随便看一眼就过去了,或者发现问题不愿意修改。要真正做好CodeReview,CodeReview必须成为团队的一种文化。开发者发自内心地接受并认真执行。形成这样的文化并没有那么容易,也没有想象中的那么难。比如可以参考这几个方面:首先,开发者必须意识到CodeReview给自己和团队带来的好处。那么,一定有几个人做出表率。榜样的力量非常重要。另外,对于管理者来说,你所激励的往往就是你所得到的。最后,就像写自动化测试一样,把CodeReview作为开发任务的一部分,给reviewer和reviewee都留出专门的时间来做这件事。不能光想着马跑得快,舍不得给马。草。如何形成这样的文化,如果你有心,有很多方法可以尝试。只有大家认同并实践,才有可能把CodeReview做好。CodeReview的一些经验技巧在做好CodeReview这件事上,有一些经验技巧可以参考。①选择什么工具辅助CodeReview?现在很多源代码管理工具都有自己的CodeReview工具,典型的有Github、Gitlab、MicrosoftAzureDevOps,尤其是Gitlab,也可以自己在本地搭建环境,根据自己的需要灵活配置。②什么样的开发流程比较好?像GithubFlow这样基于分支的开发流程特别适合CodeReview。其实不管是哪种开发流程,最关键的一点是在将代码合并到Master(主干)之前做一次CodeReview。③遇到紧急情况,来不及进行codereview怎么办?虽然原则上CodeReview是必须合并的,但是有时候也会出现一些突发情况,比如在线故障补丁,别人不在线。这种情况最好在任务管理系统中创建一个Ticket用于后续,保证后面有CodeReview加入,并且有CodeReview结果的后续代码更新。④先设计后编码。有的新人发现,把自己的代码作为PR(PullRequest)提交后,会收到一堆CodeReview的意见,很多地方都要改。这多半是因为项目开始前没有做好设计,完成后才发现很多问题。建议在做一个新的功能之前,先写一个简单的设计文档,把自己的设计思路表达清楚,找个资深的同事帮你做设计评审,发现设计问题。设计没有问题,然后开始开发,然后到Review的时候,相对的问题就会少一些。⑤提交代码进行CodeReview之前,作者必须先自己review和测试。我在做codereview的时候,有时候会发现一些很明显的问题,有些问题连自己都没有测试过,所以就等着别人来CodeReview测试帮助发现问题。这种依赖,对自己和团队都是非常不负责任的。一个好的开发人员在提交CodeReview之前一定要对代码进行Review,把该写的自动化测试代码写好,自己跑基本的测试用例。对于团队提交的PR,我有一个需求是在PR的描述中添加截图或者录屏,只是为了保证提交PR的人已经通过截图或者录屏的方式先测试过了。这也是一种有效的帮助。⑥PR要小。在做CodeReview的时候,如果有大量的文件修改,review非常困难,但是如果PR比较小,review就相对容易,很容易发现代码中可能存在的问题。因此,在提交PR时,PR应该很小。如果是比较大的改动,最好分批提交,减轻审稿人的压力。⑦给评论打分在做CodeReview时,需要对已经被review过的代码行添加评论。如果只是评论,有时被评论者很难识别评论的意思,是否必须修改。建议Review评论可以打分,不同级别的结果可以打上不同的Tag,例如:[blocker]:在评论前加一个[blocker]标签,说明这行的问题必须修改代码。[optional]:在注释前加一个[optional]标签,表示这行代码的问题可以改也可以不改。[问题]:在评论前加一个[问题]标记,表示你不理解这行代码,你有问题想问,需要被审核者回复并澄清问题。这样打分可以帮助被审稿人直观地了解Review结果,提高Review效率。⑧评论要友善,避免负面词汇;不清楚的问题面对面沟通虽然评论是CodeReview主要的沟通方式,但不要过分依赖评论。有时面对面的交流效率更高,也更容易消除误会。另外,文明用语,不要使用一些消极的词语。总结CodeReview是一个非常好的开发实践,如果你还没有开始,不妨一步一步来实践。如果效果不好,不妨对比一下,看看CodeReview是不是开发过程中必须的,而不是一个选项?您是否已将CodeReview转变为一种开发文化而不仅仅是一个系统?