我一直认为Code Review是软件开发中的最佳实践之一，可以有效提高整体代码质量，并及时发现代码中可能存在的问题。包括Google、微软这样的公司，Code Review是一项基本要求，在代码合并之前必须有人进行审查。
然而，对于我观察到的大多数软件开发团队来说，认真做Code Review的人很少。有些只是形式，有些可能根本没有代码审查。代码的质量只依赖于测试后的测试。 。也有一些团队想做好代码审查，但不知道如何做得更好。
网上已经有很多关于如何进行Code Review的文章了。这里我结合自己的一些经验，总结一下Code Review的最佳实践。希望对大家做Code Review有所帮助。
许多团队或个人不做Code Review。根本原因是他们不认为这是一件有意义的事情，不认为它有任何好处。这个问题需要从几个角度来看。
在一个开发团队中，水平有高有低，每个人的侧重点也可能不同。如何让高层帮助新人成长？如何让每个人都了解他们关注领域之外的知识？一个人离开后，如何让其他人迅速接手？这些都是团队管理者关心的问题。
代码审查是分享知识的好方法。通过代码审查，专家可以直接指出新手代码中的问题，新手可以立即从专家的反馈中学习到好的做法，更快成长；通过Code Review，前端还可以学习后端的代码，制作功能模块。 A可以了解功能模块B。
一些专家可能会觉得新手进行代码审查是浪费时间，而且一无所获。事实上，情况并非如此。随着新人的成长，他们将能够与专家分担更艰巨的任务；如果他们把时间花在代码审查上，那么他们帮助新人填坑、擦屁股的时间就会减少；良好的沟通能力、发现问题的能力、帮助他人的能力的成长是从技术向管理转型或者在技术上迈向更高层次不可或缺的能力，而代码审查可以有效地锻炼这些能力。
现实项目总是缺乏人力和进度，因此被压缩的往往是自动化测试和代码审查。这样一来，代码质量受到影响，欠下了技术债，最后还得二次偿还。
也有人把希望寄托在开发后的手动测试上。但对于代码质量来说，很多问题是无法通过测试来检验的，只能通过code review来通过。比如代码的可读性和可维护性、代码的结构、某些条件触发的无限循环、逻辑算法错误以及一些安全漏洞也更容易通过代码审查来发现和预防。
也有人认为自己级别高就不需要代码审查。对于专家来说，让其他人审查自己的代码可以让其他人学习良好的实践；在让别人审查并向别人解释自己的代码的同时，就相当于审查了自己的代码。 。这其实和我们在学校做数学题的时候是一样的。真正能得到高分的人，都是做完后会仔细检查的人。
每个团队都有自己的代码规范，以及基于架构设计的自己的开发规范。然而，久而久之，你会发现代码中有很多不符合代码规范的情况，也有很多绕过架构设计的代码。 。比如难以理解、不规范的命名，比如三层架构中UI层绕过业务逻辑层直接调用数据访问层代码。
如果这些代码违规纠正得太晚，后续的修改成本会非常高，团队的规范也会逐渐失效。
通过代码审查，可以及时发现并纠正这些问题，保证团队规范的执行。
代码审查的好处还有很多，我就不一一列举了。我还是希望认识到Code Review和写自动化测试一样，是一项需要磨刀霍霍的工作。投入一点时间就会在未来收获代码质量并节省整体开发时间。
现在很多人都意识到了Code Review的重要性，但他们就是不知道如何实践它，以及什么是好的Code Review实践。
很久以前，我尝试将代码审查作为代码流程的一部分，但这只是一个选项。代码可以合并到master中，无需Code Review。结果就是你只有在想到的时候才去做Code Review。当你去检查的时候，代码改动太多了，审核起来非常困难。另外，即使审核过程中出现问题，也很难修改。
我们现在将代码审查作为开发过程中的必需选项。每次我们开发新功能或修复错误时，我们都会打开一个新分支。分支合并到master有两个必要条件：
图片来源：如何像人类一样进行代码审查
通过将代码审查作为开发过程中的必需选项，可以很好地保证代码在合并之前经过代码审查。而且，这种在合并之前要求进行代码审查的过程的好处也很明显：
如果你觉得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）特别适合代码审查。其实，无论什么样的开发流程，关键是在代码合并到master（主干）之前，必须先做一次Code Review。
虽然原则上来说Code Review是需要合并的，但有时候会出现一些紧急情况，比如在线修补故障而其他人都不在线。这种情况最好在任务管理中进行。系统中会创建Ticket进行后续跟踪，以确保未来Code Review完成，并且Code Review结果有后续代码更新。
一些新人发现，将代码提交到 PR（Pull Request）后，会收到很多 Code Review 评论，必须进行很多更改。这可能是因为我们开始做之前没有设计好，做完之后发现了很多问题。
建议在做新功能之前，先写一份简单的设计文档，清晰表达你的设计思路，并找资深人士先帮你审核设计，发现设计问题。如果设计没有问题，那么就开始开发，那么到Review的时候，问题就会相对少一些。
我在做Code Review的时候，有时候会发现一些非常明显的问题，有些问题连我自己都没有测试过，所以我在等待别人通过Code Review和测试来帮我找到问题。这种依赖对于自己和团队都是非常不负责任的。
一个好的开发人员在提交Code Review之前一定要自己对代码进行review，写出该写的自动化测试代码，自己运行基本的测试用例。
我对团队提交的PR的要求之一是在PR的描述中添加屏幕截图或屏幕录制。这是为了确保提交 PR 的人首先通过屏幕截图或屏幕录制进行了测试。这也是一种有效的辅助。
在做Code Review的时候，如果有大量的文件修改，那么review起来会非常困难。但是如果 PR 比较小，审查起来就会相对容易，也很容易发现代码中可能存在的问题。
所以提交PR的时候，PR要小。如果是比较大的改动，最好分批提交，减少审稿人的压力。
在做Code Review时，需要对review时出现问题的代码行添加注释。如果只是评论，有时被评论者很难识别评论的含义以及是否必须修改。
建议Review评论可以分级，不同级别的结果可以标注不同的标签，例如：
这样的评分可以帮助审稿人直观地了解审稿结果，提高审稿效率。
虽然注释是Code Review沟通的主要方式，但也不要过分依赖它。有时面对面的沟通效率更高，也能轻松消除误会。
另外，使用文明用语，不要使用负面词语。
Code Review 是一种非常好的开发实践。如果你还没有开始，不妨循序渐进地练习；如果你已经做了，但效果不佳，不妨检查一下Code Review是否是开发过程中的必选选项。不可选？您是否已将代码审查转变为一种开发文化而不仅仅是一个系统？
