Code Review（代码审查）的最佳实践

我一直认为Code Review（标识符审核）是软件设计中的最差课堂教学之一，能有效率提高整体标识符产品质量，及时处理标识符中可能将存在的难题。包括像Google、谷歌那些公司，Code Review都是基本要求，代码合并之前必须要没人审核透过才行。

不过对我观察到的大部分软件设计项目组而言，深入细致做Code Review的很少，有的是形同虚设，有的是可能将根本就没有Code Review的环节，标识符产品质量只倚赖事前的试验。也很多项目组想搞好标识符审核，但不知道是不是做比较好。

网上关于如何做Code Review的文章已经有许多了，这里我结合他们的许多经验，也总结整理了一下Code Review的最差课堂教学，希望能对我们搞好Code Review有所协助。

Code Review有什么益处？

许多项目组或个人不做Code Review，根本原因却是不真的这是一件有意义的事情，不真的有什么益处。这个难题要从几个视角来看。

一个合作开发项目组中，水准B100，每个人著重的应用领域也有不同。是不是让高水准的协助后辈高速成长？是不是让我们都对他们著重应用领域之外的科学知识保持介绍？是不是能没人离任后他们能快速接掌？那些都是项目组运营者关心的问题。

而标识符审核，就是一个很好的科学知识共享资源的方式。透过标识符审核，剑客能直接指出初学者标识符中的难题，初学者能马上从剑客的意见反馈中自学到好的课堂教学，得到更慢的高速成长；透过标识符审核，后端也能去自学后端标识符，做功能模块A的能去介绍模块B的。

可能将很多剑客真的给初学者标识符审核无用，他们也没收获。众所周知，后辈高速成长了，就能更多的帮剑客分摊紧迫的任务；标识符审核地鸣鼠天数，就少许多帮后辈填坑特雷隆的天数；良好的沟通潜能、辨认出难题的潜能、协助他们高速成长，都是控制技术转管理或控制技术上更上层楼不可或缺的潜能，而透过标识符审核能有效率的去练那些方面的潜能。

现实中的项目总是人手不足缺工程进度紧，所以被填充的常常就是智能化试验和标识符审核，结果影响标识符产品质量，无力偿还债务控制技术债务，最后却是要减半偿还债务。

也没人指望合作开发后的人工试验，不过对标识符产品质量而言，许多难题透过试验是试验不出来的，只能透过标识符审核。比如说说标识符的时效性可移植性，比如说标识符的结构，比如说许多个别情况才促发的进退两难、逻辑演算法错误，还有许多安全上的安全漏洞也更容易透过标识符审核辨认出和预防。

也没人真的他们水准高就不需要标识符审核了。对剑客而言，让自己审核他们的标识符，能让他们自学到好的课堂教学；在让他们审核的同时，在给自己说明他们标识符的时候，也等于他们对他们的标识符进行了一次审核。这其实就跟我们沙朗通做解题一样，真正能拿最高分的常常是那些略过后还会深入细致检查的。

每个项目组都有他们的标识符规范，有他们的基于架构设计的合作开发规范，不过天数一长，就会辨认出标识符中出现许多不遵守标识符规范的情况，有许多绕过架构设计的标识符。比如说难以理解和不规范的命名，比如说三层架构里面UI层绕过业务逻辑层直接调用数据访问层标识符。

如果那些违反规范的标识符被纠正的晚了，后面再要修改就成本很高了，而且项目组的规范也会慢慢的形同虚设。

透过标识符审核，就能及时的去辨认出和纠正那些难题，保证项目组规范的执行。

关于标识符审核的益处，还有许多，也不一一列举。却是希望能认识到Code Review和写智能化试验一样，都是属于磨刀不误砍柴工的工作，在上面投入一点点天数，未来会收获标识符产品质量，会节约整体的合作开发天数。

该是不是做？

现在许多人都已经有意识到Code Review的重要性了，只是苦于不知道如何去课堂教学，不知道是不是样算是好的Code Review课堂教学。

把Code Review作为合作开发流程的必选项而不是可选项

在很早以前，我就尝试过将标识符审核作为标识符流程的一部分，但只是一个可选项，没有Code Review也能把标识符合并到master。这样的结果就是想起来才会去做Code Review，去检查的时候已经有了太多的标识符变更，审核起来非常困难，另外就算审核出难题，也很难得以修改。

我们现在对标识符的审核则是作为合作开发流程的一个必选项，每次合作开发新功能或者修复Bug，开一个新的分支，分支要合并到master有两个必要条件：

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工具，典型的像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，比如说说：

类似这样的分级能协助被审核者直观介绍Review结果，提高Review效率。

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

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

另外文明用语，不要用许多负面的词汇。

总结

Code Review是一种非常好的合作开发课堂教学，如果你还没开始，不妨逐步课堂教学起来；如果已经做了效果不好，不妨对照一下，看有没有把Code Review作为合作开发流程的必选项而不是可选项？有没有把Code Review变成一种合作开发文化而不仅仅是一种制度？

作者：宝玉