我一直认为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有两个必要条件：
•所有的是智能化试验透过•有至少一个人Code Review透过，如果是初学者的PR，还必须有资深程序员Code Review透过
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[1]这样基于分支开发的流程是特别适合搭配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://maimai.cn/article/detail?fid=1340810243&efid=SnwQrW8SefuDnozIUO9ztg&from=timeline
