作者：@宝玉 原文：https://zhuanlan.zhihu.com/p/...
前言
我始终认为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后果有后续的代码更新。
先设计再编码
有些新人发现自己的代码提交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，比如说：
- [optional]：在评论后面加上一个[optional]标记，示意这个代码行的问题可改可不改
- [question]：在评论后面加上一个[question]标记，示意对这个代码行不了解，有问题须要问，被审查者须要针对问题进行回复廓清
相似这样的分级能够帮忙被审查者直观理解Review后果，进步Review效率。评论要敌对，防止负面词汇；有说不清楚的问题当面沟通 尽管评论是次要的Code Review沟通形式，但也不要过于依赖，有时候面对面的沟通效率更高，也容易打消误会。另外文明用语，不要用一些负面的词汇。
总结
Code Review是一种十分好的开发实际，如果你还没开始，无妨逐渐实际起来；如果曾经做了成果不好，无妨对照一下，看有没有把Code Review作为开发流程的必选项而不是可选项？有没有把Code Review变成一种开发文化而不仅仅是一种制度？
逆锋起笔是一个专一于程序员圈子的技术平台，你能够播种最新技术动静、最新内测资格、BAT等大厂大佬的教训、增长本身、学习材料、职业路线等等，微信搜寻逆锋起笔关注！