Code Review(代码评审)是每一位软件工程师都应该掌握的基本技能，任何一个成熟的研发团队都会对代码评审给予足够的重视。本文概括的解释了为什么代码评审有用以及如何做代码评审，最后给出了一个代码评审需要注意的清单列表。原文：The Comprehensive Code Review Checklist[1]
代码评审是团队提高代码质量的有用工具，不过，评审代码还有许多其他好处，比方说在研发生命周期的早期捕获 bug、共享知识以及改进团队的评估技能。
本文将解释什么是代码评审，为什么应该进行代码评审，如何准备代码评审，以及如何给出可操作的反馈。在本文的最后一部分，提供了开发人员在工作流程中进行代码评审时可以参考的代码评审检查清单。
首先，我们需要理解什么是代码评审？
什么是代码评审？
代码评审的目的是提高我们想要添加到代码库中的代码的质量。代码评审是一种系统的方法，用来评审其他开发者代码中的错误，以及许多其他质量指标。此外，代码评审需要确认是否所有需求都已正确实现。
在大多数开发团队中，开发人员会提交一个 Pull Request (PR)来向代码库中添加代码。一个或多个团队成员将被指派审查代码，检查代码是否符合质量标准，并添加必要的文档。
然而，代码评审不仅仅是质量检查。通过让多个开发人员评审一个 PR，他们将接触到新的代码，为了完成代码评审，评审人员必须理解 PR 的上下文和范围。因此，代码评审是减少技术债务的很好的工具。
此外，代码评审对开发人员来说是一个宝贵的学习机会。这是一个获得关于代码和编码风格反馈的好机会。
为什么需要做代码评审？
有许多明显的好处和原因可以用来说明为什么团队需要进行代码评审。
前面已经提到了其中一些好处，代码评审为开发人员提供了一个很好的机会来提高他们的编码技能并获得有价值的反馈。此外，这也是在不同团队成员之间积极分享知识的好工具，可以防止“单点知识故障”。代码评审意味着许多人都对代码库的特定部分有经验或了解。例如，当某个特定的开发人员在度假（或生病），并且需要有人检查针对该开发人员专业领域的代码时，可能会很有用。
代码评审的一个不太明显的 ROI 度量是通过尽早捕获 bug 来降低开发成本，代码评审可以帮助我们发现那些通过测试或自动代码检查工具无法检测到的错误。
最后，代码评审可以帮助我们提高评估技能，Atlassian 为此提供了一个很好的解释（https://www.atlassian.com/agile/software-development/code-reviews）。
“评估是一项团队活动，当产品知识在团队中传播时，团队可以做出更好的评估。随着新功能被添加到现有的代码中，最初的开发者可以提供良好的反馈和评估。”
那么，应该如何为代码评审做准备呢？
为代码评审做准备
在开始评审之前，请确保我们拥有评审所需的所有信息，我们不希望因为无法获得完成整个过程所需的信息而被迫在中途停下来。
同时，确保理解 PR 的上下文和范围，这将使得评审代码和检查需求更加容易。我总是建议开发人员尝试运行代码并使用调试器来更深入理解代码是如何工作的。
Ilya Pavlov@Unsplash
如何给出具体和可操作的反馈？
首先，确保营造一个友好的氛围。代码评审不是批评同事的工具，我们想要创造一个支持性的环境。
最好的方法是提供友好的建议，解释你的理由，并给出改进代码的提示。你不会想告诉 PR 所有者这段代码不好。一定要包含理由，给出建议，甚至是代码片段来提高 PR。PR 所有者会喜欢这些反馈，这是一个学习新东西的好机会。
小贴士：问问题而不是做陈述。如果你这么做，你就迫使 PR 所有者思考自己的代码，并找到更好的解决方案。换句话说，你为 PR 负责人创造了一个可操作的学习机会。但是，不要忘记添加足够的反馈，让 PR 负责人理解你的问题。
代码评审清单
清单可以帮助我们创建代码评审的结构化方法。此外，还会提醒我们需要执行的所有质量检查，以批准代码进入代码库。
可以在代码检查清单中包含许多特定的项目。以下是一些应该经常留意的必备条目的概述。
1. 确认功能需求
一旦我们理解了 PR 的上下文，就该验证需求了。我们需要确保 PR 涵盖了特性单所描述的所有需求。如果缺少了什么或者实现的不正确，应该停止代码评审，并要求开发人员完成 PR。我们不想在代码可能发生变化时浪费时间评审其余的代码。
2. 代码可读性
一旦验证了需求，就该看看可读性了。我们应该问自己的主要问题是：“代码是自解释的吗？”如果发现某个函数不可读，建议将代码分解或重新组织，以提高其他开发人员的可读性。
3. 代码风格
大多数开发团队更喜欢定义一个编码风格指南，我们可以基于此指南来检查代码。同样，使用相同的编码风格将提高代码的可读性。
4. 清晰的命名
验证函数和变量是否具有描述性。为了提高可读性，应该通过查看函数名和变量来理解模块或类的功能。许多开发者使用这种方法来快速理解新 PR 的范围和背景。因此，开发人员必须使用清晰的命名。
5. 冗余代码
确保检查是否有冗余的代码。新团队成员有时不知道已经存在哪些函数或库，因此，当这个功能已经存在时，他们可能创建了自己的库。为了保持代码库的整洁，请检查是否有代码冗余。
6. 测试
始终检查实现的测试是否覆盖所有编码路径，确保将任何遗漏的测试标记给 PR 所有者。
7. 文档
最后，在向代码库添加新特性时，开发人员应该更新文档。但是，不要忘记检查文档的质量。
结论
代码评审是开发团队的一件趁手的工具。
请记住，代码评审是针对团队中的每个人的。一些公司错误地将代码评审作为向初级团队成员提供高级团队成员反馈的一种方式。反之亦然。团队中的任何开发人员都可以学习、改进和分享知识。
References:
[1] The Comprehensive Code Review Checklist: https://hackernoon.com/the-comprehensive-code-review-checklist
