Code Review最佳实践

我一直认为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经过

图片来源：How to Do Code Reviews Like a Human

这样把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结果有后续的代码更新。

先设计再编码

有些新人发现本身的代码提交PR（Pull 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，好比说：

• [blocker]: 在评论前面加上一个[blocker]标记，表示这个代码行的问题必需要修改
• [optional]：在评论前面加上一个[optional]标记，表示这个代码行的问题可改可不改
• [question]：在评论前面加上一个[question]标记，表示对这个代码行不理解，有问题须要问，被审查者须要针对问题进行回复澄清 

相似这样的分级能够帮助被审查者直观了解Review结果，提升Review效率。

评论要友好，避免负面词汇；有说不清楚的问题当面沟通 

虽然评论是主要的Code Review沟通方式，但也不要过于依赖，有时候面对面的沟通效率更高，也容易消除误解。

另外文明用语，不要用一些负面的词汇。 

总结 

Code Review是一种很是好的开发实践，若是你还没开始，不妨逐步实践起来；若是已经作了效果很差，不妨对照一下，看有没有把Code Review做为开发流程的必选项而不是可选项？有没有把Code Review变成一种开发文化而不只仅是一种制度？

原文出处：https://www.cnblogs.com/dotey/p/11216430.html