物流公司网站模版,深圳建站公司收费,上海有几个区域,临沂网站建设有哪些Code Review最佳实践
Code Review
我一直认为Code Review#xff08;代码审查#xff09;是软件开发中的最佳实践之一#xff0c;可以有效提高整体代码质量#xff0c;及时发现代码中可能存在的问题。包括像Google、微软这些公司#xff0c;Code Review都是基本要求代码审查是软件开发中的最佳实践之一可以有效提高整体代码质量及时发现代码中可能存在的问题。包括像Google、微软这些公司Code Review都是基本要求代码合并之前必须要有人审查通过才行。然而对于我观察到的大部分软件开发团队来说认真做Code Review的很少有的流于形式有的可能根本就没有Code Review的环节代码质量只依赖于事后的测试。也有些团队想做好代码审查但不知道怎么做比较好。网上关于如何做Code Review的文章已经有很多了这里我结合自己的一些经验也总结整理了一下Code Review的最佳实践希望能对大家做好Code Review有所帮助。
Code Review有什么好处 很多团队或个人不做Code Review根源还是不觉得这是一件有意义的事情不觉得有什么好处。这个问题要从几个角度来看。 首先是团队知识共享的角度 一个开发团队中水平有高有低每个人侧重的领域也有不同。怎么让高水平的帮助新人成长怎么让大家都对自己侧重领域之外的知识保持了解怎么能有人离职后其他人能快速接手这些都是团队管理者关心的问题。 而代码审查就是一个很好的知识共享的方式。通过代码审查高手可直接指出新手代码中的问题新手可以马上从高手的反馈中学习到好的实践得到更快的成长通过代码审查前端也可以去学习后端的代码做功能模块A的可以去了解功能模块B的。 可能有些高手觉得给新手代码审查浪费时间自己也没收获。其实不然新人成长了就可以更多的帮高手分担繁重的任务代码审查中花时间就少一些帮新人填坑擦屁股的时间良好的沟通能力、发现问题的能力、帮助其他人成长都是技术转管理或技术上更上一层楼必不可少的能力而通过代码审查可以有效的去练习这些方面的能力。 然后是代码质量的角度 现实中的项目总是人手缺进度紧所以被压缩的往往就是自动化测试和代码审查结果影响代码质量欠下技术债务最后还是要加倍偿还。 也有人寄希望于开发后的人工测试然而对于代码质量来说很多问题通过测试是测试不出来的只能通过代码审查。比如说代码的可读性可维护性比如代码的结构比如一些特定条件才触发的死循环、逻辑算法错误还有一些安全上的漏洞也更容易通过代码审查发现和预防。 也有人觉得自己水平高就不需要代码审查了。对于高手来说让别人审查自己的代码可以让其他人学习到好的实践在让其他人审查的同时在给别人说明自己代码的时候也等于自己对自己的代码进行了一次审查。这其实就跟我们上学时做数学题一样真正能拿高分的往往是那些做完后还会认真检查的。 还有团队规范的角度 每个团队都有自己的代码规范有自己的基于架构设计的开发规范然而时间一长就会发现代码中出现很多不遵守代码规范的情况有很多绕过架构设计的代码。比如难以理解和不规范的命名比如三层架构里面UI层绕过业务逻辑层直接调用数据访问层代码。 如果这些违反规范的代码被纠正的晚了后面再要修改就成本很高了而且团队的规范也会慢慢的形同虚设。 通过代码审查就可以及时的去发现和纠正这些问题保证团队规范的执行。 关于代码审查的好处还有很多也不一一列举。还是希望能认识到Code Review和写自动化测试一样都是属于磨刀不误砍柴工的工作在上面投入一点点时间未来会收获代码质量会节约整体的开发时间。
该怎么做
现在很多人都已经有意识到Code Review的重要性了只是苦于不知道如何去实践不知道怎么样算是好的Code Review实践。
把Code Review作为开发流程的必选项而不是可选项
在很早以前我就尝试过将代码审查作为代码流程的一部分但只是一个可选项没有Code Review也可以把代码合并到master。这样的结果就是想起来才会去做Code Review去检查的时候已经有了太多的代码变更审查起来非常困难另外就算审查出问题也很难得以修改。我们现在对代码的审查则是作为开发流程的一个必选项每次开发新功能或者修复Bug开一个新的分支分支要合并到master有两个必要条件所有的自动化测试通过有至少一个人Code Review通过如果是新手的PR还必须有资深程序员Code Review通过这样把Code Review作为开发流程的一个必选项后就很好的保证了代码在合并之前有过Code Review。而且这样合并前要求代码审查的流程好处也很明显 由于每一次合并前都要做代码审查这样一般一次审查的代码量也不会太大对于审查者来说压力也不会太大如果在Code Review时发现问题被审查者希望代码能尽快合并也会积极的对审查出来的问题进行修改不至于对审查结果太过抵触 如果你觉得Code Review难以推行不妨先尝试着把Code Review变成你开发流程的一个必选项。
把Code Review变成一种开发文化而不仅仅是一种制度
把Code Review 作为开发流程的必选项后不代表Code Review这件事就可以执行的很好因为Code Review 的执行很大部分程度上依赖于审查者的认真审查以及被审查者的积极配合两者缺一不可如果仅仅只是当作一个流程制度那么就可能会流于形式。最终结果就是看起来有Code Review但没有人认真审查随便看下就通过了或者发现问题也不愿意修改。真要把Code Review这件事做好必须让Code Review变成团队的一种文化开发人员从心底接受这件事并认真执行这件事。要形成这样的文化不那么容易也没有想象的那么难比如这些方面可以参考 首先得让开发人员认识到Code Review这件事为自己、为团队带来的好处然后得要有几个人做好表率作用榜样的力量很重要还有对于管理者来说你激励什么往往就会得到什么最后像写自动化测试一样把Code Review要作为开发任务的一部分给审查者和被审查者都留出专门的时间去做这件事不能光想着马儿跑得快又舍不得给马儿吃草 如何形成这样的文化有心的话还有很多方法可以尝试。只有真正让大家都认同和践行才可能去做好Code Review这件事。
一些Code Review的经验技巧
在做好Code Review这件事上还有一些经验技巧可以参考。
选什么工具辅助做CODE REVIEW
现在很多源代码管理工具都自带Code Review工具典型的像Github、Gitlab、微软的Azure DevOps尤其是像Gitlab还可以自己在本地搭建环境根据自己的需要灵活配置。
配合什么样的开发流程比较好
像Github Flow这样基于分支开发的流程是特别适合搭配Code Review的。其实不管什么样的开发流程关键点在于代码合并到master主干之前要先做Code Review。
真遇到紧急情况来不及代码审查怎么办
虽然原则上必须要Code Review才能合并但有时候确实会存在一些紧急情况比如说线上故障补丁而又没有其他人在线那么这种情况下最好是在任务管理系统中创建一个Ticket用来后续跟踪确保后续补上Code Review并对Code Review结果有后续的代码更新。
先设计再编码
有些新人发现自己的代码提交PRPull Request后会收到一堆的Code Review意见必须要做大量的改动。这多半是因为在开始做之前没有做好设计做出来后才发现问题很多。建议在做一个新功能之前写一个简单的设计文档表达清楚自己的设计思路找资深的先帮你做一下设计的审查发现设计上的问题。设计上没问题了再着手开发那么到Review的时候相对问题就会少很多。
代码在提交CODE REVIEW之前作者要自己先REVIEW和测试一遍
我在做代码审查的时候有时候会发现一些非常明显的问题有些甚至自己都没有测试过就等着别人Code Review和测试帮助发现问题。这种依赖心理无论是对自己还是对团队都是很不负责任的。一个好的开发人员代码在提交Code Review之前肯定是要自己先Review一遍把该写的自动化测试代码写上自己把基本的测试用例跑一遍的。我对于团队提交的PR有个要求就是要在PR的描述中增加截图或者录屏就是为了通过截图或者录屏确保提交PR的人自己是先测试过的。这也是一个有效的辅助手段。
PR要小
在做Code Review的时候如果有大量的文件修改那么Review起来是很困难的但如果PR比较小相对就比较容易Review也容易发现代码中可能存在的问题。所以在提交PR时PR要小如果是比较大的改动那么最好分批提交以减轻审查者的压力。
对评论进行分级 在做Code Review时需要针对审查出有问题的代码行添加评论如果只是评论有时候对于被审查者比较难甄别评论所代表的含义是不是必须要修改。 建议可以对Review的评论进行分级不同级别的结果可以打上不同的Tag比如说 [optional]在评论前面加上一个[optional]标记表示这个代码行的问题可改可不改 [question]在评论前面加上一个[question]标记表示对这个代码行不理解有问题需要问被审查者需要针对问题进行回复澄清 类似这样的分级可以帮助被审查者直观了解Review结果提高Review效率。
评论要友好避免负面词汇有说不清楚的问题当面沟通
虽然评论是主要的Code Review沟通方式但也不要过于依赖有时候面对面的沟通效率更高也容易消除误解。另外文明用语不要用一些负面的词汇。
总结
Code Review是一种非常好的开发实践如果你还没开始不妨逐步实践起来如果已经做了效果不好不妨对照一下看有没有把Code Review作为开发流程的必选项而不是可选项有没有把Code Review变成一种开发文化而不仅仅是一种制度
-----------------------------------------------------------------------------------
offer突击训练营简介
1针对不知道怎么面试面试没有信心的小伙伴我们会给你一个offer保障。
2我们会监督你15-20天内把面试体系技术点掌握至少7成这样足够你去找到满意的工作了。
3我们是面向面试学习指导不会带你们去写代码会把项目真实开发的迭代过程和技术细节如何实现业务功能都详细教清楚你能在面试中流畅表达清楚就行了项目经验你不用担心(技术老师提供的真实项目经验肯定拿的出手)自己学和别人带着系统学效率完全不一样。
详情请点击这里offer突击训练营给你一个offer的保障求职跳槽的看过来
