软件开发生命周期中至关重要的一步是代码审查。它使开发人员能够显著提升代码质量。它类似于书籍的创作过程。首先，作者写故事，然后经过编辑以确保不会出现诸如混淆“you’re”和“yours”之类的错误。在这个语境中，代码审查指的是检查和评估他人的代码。它基于拉取请求模型，这个模型在开源项目中广受欢迎。
代码审查有不同的好处：
•确保设计和实现的一致性，•优化代码以提升性能，•是学习的机会，•知识分享和指导，以及促进团队凝聚力。
代码审查中需要检查的内容
代码审查有不同的好处：
在代码审查中应该查找什么？有许多不同的事项需要检查，从重要性的不同层次和自动化的可能性来看：
尝试查找以下内容：
1.功能性和设计 — 这里，我们需要找到答案，比如：这个更改是否遵循我们期望的架构，或者它是否与系统的其他部分集成良好？它的组件之间是否具有高内聚性和低耦合性？它是否遵循了如OO、SOLID、DRY、KISS、YAGNI等健壮的原则？2.实现 — 在这里，我们检查解决方案是否在逻辑上正确（它确实改变了开发人员的意图），如果代码比应有的复杂，等等。这段代码是否必要？我们还要检查是否使用了良好的设计模式。以及关键的内容，例如API入口点。3.测试 — 在这里，我们检查是否所有测试都通过了，我们是否对所有代码路径和行为使用单元测试，并对外部系统（数据库、文件系统等）使用集成测试。我们是否检查了所有边界条件和代码覆盖率在60-80%之间？4.文档 — 我们的PR描述添加了吗？我们的解决方案在存储库的README.md或其他地方是否有文档更新？5.代码风格 — 我们是否遵循了项目的代码风格？您是否知道命名是否良好？开发人员是否为类、方法等选择了确切的名称？代码是否易读？
代码审查金字塔（基于Gunnar Morling的原始作品）
进行代码审查的一些良好实践
以下是进行代码审查时的一些良好实践：
1.尝试首先审查您自己的代码。
在将代码发送给同事之前，尝试先阅读和理解它。寻找让您困惑的部分。在IDE之外查看您的代码通常有助于将其视为“新”的东西，从而避免操作性盲点。
1.编写更改的简短描述。
这应该以高层次解释更改内容以及为何进行这些更改的方式来解释。
1.自动化可以自动化的部分。
将所有可以自动化的工作留给系统，例如检查成功构建（CI）、样式更改（代码检查器）、自动化测试和静态代码分析（例如使用SonarQube）。我们已将其集成在PR级别，因此它将在每个PR上运行并为代码合并提供阻碍。这将使我们能够消除不必要的讨论，为更重要的讨论留出空间。
1.为更大的任务与团队成员进行启动会议。
如果您开始处理更大的任务，特别是在设计方面，请尝试首先与代码所有者或将成为您的代码审查者的人进行启动会议。这将在实施之前达成共识，并减少在PR审查阶段的工作量，避免出现意外情况。
1.不要着急
您需要了解其周围发生了什么 — 每一行代码。如果需要，逐类多次阅读。应该查看分配给审查的每一行代码。有些代码需要更多的思考，有些则需要更少，但这是我们在审查过程中必须做出的决定。如果需要，为口头讨论保持自己的时间。
1.友善地评论
永远不要提及个人（您），始终将注意力集中在更改上，以问题或建议的形式提出，并留下至少一个积极的评论。用您的话解释“为什么”，并建议如何改进。
1.在足够好时批准PR。
不要追求完美，但要保持高标准。不要小题大做。
1.控制审查的规模。
我们应该限制一次审查的代码行数。PR应该包含尽可能少的更改文件。我更喜欢更小的增量更改而不是重大的更改。我们的大脑无法一次处理那么多信息。每次审查的核心行数的理想数量是200到400行，通常是60到90分钟。如果任务庞大，请将其细分为可以快速审查的较小子任务。
1.使用工具
对于所有代码审查，您应该使用一些工具，例如BitBucket、Azure DevOps、GitHub或GitLab。例如，Microsoft多年来一直使用名为CodeFlow的内部工具，它支持开发人员并指导他们完成所有代码审查步骤。它在代码准备阶段有所帮助，自动通知审阅者，并具有丰富的评论和讨论功能。在后来的几年里，他们转向了GitHub拉取请求。Google也在代码审查方面使用两种解决方案。他们使用Gerrit代码审查工具进行开源代码审查，但在内部代码方面，他们使用名为Critique的内部工具。
代码审查的更好替代方案
除了传统的PR审查之外，还有另一种模型可以帮助您在编码过程中获得更高的效率和速度。它基于一种不同于拉取请求的模型，称为基于主干的开发。在这里，您同步进行代码审查。通过这种方式，所有开发人员都在主线分支上工作，频繁提交更改。这种做法的一个例子是协作编程方法（配对编程和集体编程），是由Kent Beck在90年代作为极限编程技术引入的。
配对编程（来源：Unsplash）
配对编程和集体编程是协作编程方法，涉及两个或多个开发人员共同处理单个任务，共享编写代码时的想法和思路。在这里，一个开发人员充当驱动者（编写代码）的角色，而另一个则充当导航者的角色（确保代码准确性）。在过程中他们会定期交换位置。
与传统代码审查相比，这些方法提供了多种好处：
•实时反馈：配对编程和集体编程使开发人员能够即时获得有关其代码的反馈，从而能够解决问题并改进。这与传统的代码审查不同，后者可能要等到代码审查阶段才会收到反馈。•增强的知识共享：协作编程使开发人员能够从彼此的经验和知识中学习，从而带来更好的代码和技能发展。这在使用新技术或面对新手时特别有用。此外，学习更容易在团队成员之间传播，降低了单个开发人员成为瓶颈的风险。•更快的问题解决鼓励开发人员共同解决问题，从而获得更快、更高效的解决方案。这可以减少开发时间并改善项目结果。•增强的关注和生产力：与另一位开发人员密切合作可以帮助保持专注并减少分心。•提高代码质量：当多个开发人员共同合作时，他们更有可能在开发早期发现错误和设计问题，进而提高代码质量。
这种方法在拥有大部分资深开发人员的团队，必须快速迭代的情况下效果最佳。然而，如果团队主要由初级开发人员组成，或者产品较为复杂需要多人审核代码时，Pull Request 模型更为适用。
