我一直认为CodeReview（代码审查）是软件开发中的最佳实践之一，可以有效提高整体代码质量，及时发现代码中可能存在的问题。图片来自Unsplash，包括谷歌和微软等公司。CodeReview是一项基本要求。在合并代码之前，必须有人对其进行审查。但是，我观察过的大部分软件开发团队，很少有人认真做CodeReview，有的流于形式，有的可能根本就没有CodeReview，代码质量只靠事后测试。也有团队想做好codereview，但是不知道如何做得更好。网上已经有很多关于如何做CodeReview的文章。这里我结合自己的一些经验，总结一下CodeReview的优秀实践。希望对大家做好CodeReview有所帮助。CodeReview有什么好处？许多团队或个人不进行代码审查。根本原因是他们还是觉得这不是什么有意义的事情，觉得没有什么好处。这个问题应该从几个角度来看。从团队知识共享的角度来看在一个开发团队中，级别有高有低，每个人的侧重点也不一样：高级别如何帮助新人成长？每个人如何才能跟上他们关注领域之外的知识？有人离开后，其他人能否迅速接手？这些都是团队管理者关心的问题。代码审查是分享知识的好方法。通过代码审查，专家可以直接指出新手代码中存在的问题，新手可以立即从专家的反馈中学习到好的做法，实现更快的成长；通过codereview，前端也可以学习到后端的代码，让功能模块A可以学习到功能模块B。有的高手可能会觉得给新手review代码很浪费时间，一无所获。其实，新人长大后，可以帮助高手分担更重的任务；花在codereview上的时间会节省新人填坑擦屁股的时间。良好的沟通能力、发现问题的能力、帮助他人成长的能力，都是将技术转化为管理或将技术提升到更高水平的必备技能，而代码审查可以有效地练习这些技能。从代码质量角度看实际项目中，总是人手不足，工期紧，压缩的往往是自动化测试和代码审查，影响代码质量，欠下技术债，必须加倍结尾。也有人寄希望于开发后的人工测试。但是对于代码质量来说，很多问题是无法通过测试发现的，只能通过codereview才能通过。比如代码的可读性和可维护性，比如代码的结构，比如某些条件触发的死循环，逻辑算法错误，还有一些安全漏洞，通过codereview更容易发现和预防。有些人认为自己水平高了就不需要codereview了。对于专家来说，让别人审查自己的代码可以让别人学习好的做法；在让别人review的同时，在给别人解释自己的代码的时候，也相当于在review自己的代码。这其实和我们上学的时候做数学题是一样的。真正能拿高分的，往往是做完后会仔细检查的人。从团队规范来看，每个团队都有自己的代码规范，也有自己基于架构设计的开发规范。但是，随着时间的推移，你会发现代码中有很多不符合代码规范的情况，也有很多绕过架构设计的情况。代码。比如难以理解和不规则的命名，比如三层架构中的UI层绕过业务逻辑层，直接调用数据访问层代码。如果这些违反规范的代码改得晚了，后期修改成本会非常高，团队的规范也会逐渐变得无用。通过codereview，可以及时发现并纠正这些问题，保证团队规范的执行。关于codereview的好处，还有很多，就不一一列举了。我还是希望认识到，CodeReview和写自动化测试一样，是磨刀霍霍的活儿。如果您在其中投入一点时间，您将在未来获得代码质量并节省整体开发时间。如何进行代码审查？现在很多人已经意识到CodeReview的重要性，但是就是不知道怎么去实践，不知道怎样才能做好CodeReview实践。①将CodeReview作为开发过程的必经之路，而不是可选项。很久以前，我尝试将代码审查作为代码流程的一部分，但这只是一个选项。代码也可以在没有CodeReview的情况下合并到Master中。这样做的结果是，您只有在想到它时才进行CodeReview。去查的时候代码改动已经太多了，review难度很大。另外，即使review有问题，也很难修改。图片来源：如何像Huma一样进行代码审查我们当前的代码审查是开发过程中必不可少的。每次开发一个新特性或者修复一个bug，都会开辟一个新的分支，有两个分支要合并到MasterPrerequisites：自动化测试全部通过。至少有一个人通过了CodeReview。如果是新手PR，肯定有通过CodeReview的资深程序员。这样，在将CodeReview作为开发过程中的必选选项之后，就很好的保证了代码在合并前进行了CodeReview。而这种在合并前要求codereview的流程好处也很明显：由于每次合并前都需要codereview，所以一般来说审查的代码量不会太大，reviewer的压力也不会太大。如果在CodeReview的时候发现问题，被review的人希望代码能尽快合并，并且会积极修改review发现的问题，以免和review的结果矛盾太大。如果你觉得CodeReview很难实现，不妨尝试让CodeReview成为你开发过程中的必经之路。②把CodeReview变成一种开发文化而不仅仅是一个系统CodeReview在开发过程中是必须的之后，并不代表CodeReview可以很好的实施，因为CodeReview的实施非常重要。一定程度上取决于审稿人的细心审稿和被审稿人的积极配合，两者缺一不可！如果仅仅把它看成一个流程体系，那么它可能流于形式。最后的结果就是好像有CodeReview，但是没有人认真审查，随便看一眼就过去了，或者发现问题不愿意修改。要真正做好CodeReview，CodeReview必须成为团队的一种文化。开发者发自内心地接受并认真执行。形成这样的文化并没有那么容易，也没有想象中的那么难。比如可以参考这几个方面：首先，开发者必须意识到CodeReview给自己和团队带来的好处。那么，一定有几个人做出表率。榜样的力量非常重要。另外，对于管理者来说，你所激励的往往就是你所得到的。最后，就像写自动化测试一样，把CodeReview作为开发任务的一部分，给reviewer和reviewee都留出专门的时间来做这件事。不能光想着马跑得快，舍不得给马。草。如何形成这样的文化，如果你有心，有很多方法可以尝试。只有大家认同并实践，才有可能把CodeReview做好。CodeReview的一些经验技巧在做好CodeReview这件事上，有一些经验技巧可以参考。①选择什么工具辅助CodeReview？现在很多源代码管理工具都有自己的CodeReview工具，典型的有Github、Gitlab、MicrosoftAzureDevOps，尤其是Gitlab，也可以自己在本地搭建环境，根据自己的需要灵活配置。②什么样的开发流程比较好？像GithubFlow这样基于分支的开发流程特别适合CodeReview。其实不管是哪种开发流程，最关键的一点是在将代码合并到Master（主干）之前做一次CodeReview。③遇到紧急情况，来不及进行codereview怎么办？虽然原则上CodeReview是必须合并的，但是有时候也会出现一些突发情况，比如在线故障补丁，别人不在线。这种情况最好在任务管理系统中创建一个Ticket用于后续，保证后面有CodeReview加入，并且有CodeReview结果的后续代码更新。④先设计后编码。有的新人发现，把自己的代码作为PR（PullRequest）提交后，会收到一堆CodeReview的意见，很多地方都要改。这多半是因为项目开始前没有做好设计，完成后才发现很多问题。建议在做一个新的功能之前，先写一个简单的设计文档，把自己的设计思路表达清楚，找个资深的同事帮你做设计评审，发现设计问题。设计没有问题，然后开始开发，然后到Review的时候，相对的问题就会少一些。⑤提交代码进行CodeReview之前，作者必须先自己review和测试。我在做codereview的时候，有时候会发现一些很明显的问题，有些问题连自己都没有测试过，所以就等着别人来CodeReview测试帮助发现问题。这种依赖，对自己和团队都是非常不负责任的。一个好的开发人员在提交CodeReview之前一定要对代码进行Review，把该写的自动化测试代码写好，自己跑基本的测试用例。对于团队提交的PR，我有一个需求是在PR的描述中添加截图或者录屏，只是为了保证提交PR的人已经通过截图或者录屏的方式先测试过了。这也是一种有效的帮助。⑥PR要小。在做CodeReview的时候，如果有大量的文件修改，review非常困难，但是如果PR比较小，review就相对容易，很容易发现代码中可能存在的问题。因此，在提交PR时，PR应该很小。如果是比较大的改动，最好分批提交，减轻审稿人的压力。⑦给评论打分在做CodeReview时，需要对已经被review过的代码行添加评论。如果只是评论，有时被评论者很难识别评论的意思，是否必须修改。建议Review评论可以打分，不同级别的结果可以打上不同的Tag，例如：[blocker]:在评论前加一个[blocker]标签，说明这行的问题必须修改代码。[optional]：在注释前加一个[optional]标签，表示这行代码的问题可以改也可以不改。[问题]：在评论前加一个[问题]标记，表示你不理解这行代码，你有问题想问，需要被审核者回复并澄清问题。这样打分可以帮助被审稿人直观地了解Review结果，提高Review效率。⑧评论要友善，避免负面词汇；不清楚的问题面对面沟通虽然评论是CodeReview主要的沟通方式，但不要过分依赖评论。有时面对面的交流效率更高，也更容易消除误会。另外，文明用语，不要使用一些消极的词语。总结CodeReview是一个非常好的开发实践，如果你还没有开始，不妨一步一步来实践。如果效果不好，不妨对比一下，看看CodeReview是不是开发过程中必须的，而不是一个选项？您是否已将CodeReview转变为一种开发文化而不仅仅是一个系统？
