无论您是哪种类型的开发人员，在团队中工作时，代码评审都是您日常职责的一部分。作为 React 开发者也不例外。有很多资源可以教你如何编写更好的 React 代码，但几乎没有任何文章、视频或教程可以帮助你改进 React 代码的审查。
尽管审查同事的代码是我们作为开发人员职责的重要组成部分，但这并不是许多开发人员所期待的责任。他们觉得读代码很无聊，作为审阅者这对你没有意义，而你唯一要做的就是为同事代码把关。
  就我个人而言，我曾经有过相同的看法，不太喜欢审查代码。但是作为 React 开发人员在这个地方花费了大量时间并深入研究了不同方面之后，我注意到问题归结为我不知道如何正确审查 React 代码这一事实。
  我的例行程序是打开合并请求 (MR)，只需从上到下阅读所有代码，无需任何策略，并对我注意到的内容添加评论。毫无疑问我不喜欢这样并且提供的评论质量也不高。
如今，我总是带着将关注的特定计划和主题来审查 React 代码。自从开始这样做以后，审查变得不那么无聊，而且审查质量随着时间的推移而提高，这是从同事那里收到的反馈。
  我甚至会说我现在真的很喜欢审查同事的代码。查看他们的代码为我提供了一种不同的方式来了解他们的编码风格、理解他们的代码、提出有关代码的问题、学习新事物，最重要的是对他们工作提供反馈以全面提高代码库的质量。
  这篇文章分享了我在审查 React 代码时问自己的所有问题。如果不确定如何审查 React 代码或不知道要关注什么，那么这些问题将帮助你开始。使用这些作为基础将使你能够像我一样创建你的审查清单，开始使审查成为一个有意识的过程，为的团队提供更有意义的审查，甚至可能开始享受它。

1. 这段代码有效吗？

  审查任何内容最重要的方面是确保代码有效。这未必是可以在代码中轻松验证的内容。大多数时候，将依赖持续集成 (CI) 或在本地自行检查代码。还希望代码以 MR 的形式提供时能够正常工作。但尽管如此，在通读代码时质疑代码是否有效也无妨。在最坏的情况下，你会更好地理解代码。在最好的情况下，你会注意到代码提交者遗漏的一些细节，这有助于提高质量。

2. 我明白发生了什么吗？

  通常，开发人员会像查看合并请求 (MR)或其他静态分析工具一样查看合并请求 (MR)。 他们只会关注代码的实现，并检查一切是否正确实现。问题是相应的静态分析工具可以更快、更高效、更可靠地完成相同的事情。虽然关注细节很好，但如果不了解代码的实际作用，它不应该成为主要关注点。
  无论是提供更有意义的反馈，还是预计未来的工作，首先必须了解正在发生的事情。在合并请求 (MR)中，与代码提交者一起思考并做静态分析工具无法做的事情时。要做到这一点，首先需要了解 合并请求 (MR)中发生了什么。这涉及到很多事情，比如上下文、目的和实现。

3. 这段代码可读性强吗？

  我们不应该只满足于有效的代码。这应该是最低要求，但不是决定因素。最后，代码必须维护合并到代码库并交付给用户。但与代码本身不同的是，创建它的开发人员不会永远使用它。几个月后，即使是创建者本身也很可能难以理解他们自己的代码。
  因此，拥有可读的代码很重要。拥有更具可读性的代码意味着其他开发人员将来能够更轻松地理解代码并执行与维护相关的任务。具体示例包括内容状态、内联条件渲染和自定义挂钩，以及代码放置位置、组织以及变量和函数的命名。
  但可读性不仅限于特定的代码模式或主题。它是关于所有代码作为一个整体以及开发人员通过代码理解它的难易程度。最后，可读性是工程团队的一项长期投资，工程团队在审查期间完成付款。

4. 这个组件或者钩子是不是做的太多了？

  软件开发中的一个经典反模式就是所谓的上帝对象。这是指承担所有职责的任何编程实例，如对象、类或函数。它会知道很多，做太多，包含太多相互交织的流程。结果是一个难以维护、理解、重构、工作并且非常脆弱的实例。同样，我们应该在 React 开发中避免这种情况。特别是对于 React，其开发重点是可重用性、可扩展性和单一职责，考虑这一点很重要。注意 React 组件和钩子，尝试理解它们的目的，并验证它们是否做得太多。如果是这样，那么明智的做法是建议通过将其抽象为组件或钩子来解决这个问题，以防止代码库的质量下降。

5. 这必须是一个组件或钩子吗？

  另一方面，抽象不够，因此可能会创建一个上帝组件或钩子，还有抽象过多的另一面。 将所有东西都变成组件或钩子最终也会降低 React 代码库的质量。在层之间有一个额外的组件可以引入 prop drilling，一个 React 特定的反模式，或者阻止推荐的组合模式。 虽然为每个逻辑片段创建一个新的自定义钩子可能会导致过多的抽象，从而使代码库变得杂乱无章。在审查时，你是代码的第一位读者，因此是体验这些后果的主要人选。牢记这一点并不断问自己所选择的结构是否必要，可以让你在不实际接触代码的情况下为代码架构做出贡献。

6. 这个 API 设计可以简化吗？

  无论是函数参数、React 组件的 props 还是自定义的 hook 参数，实现它们都不是一件容易的事。归根结底，它是一种 API 设计形式。尤其是使用 React props，很容易创建一个复杂且冗余的 API。
  如果有两个针对 UI 相似部分的布尔型props，那么考虑使用枚举props可能会更好。如果有两个总是一起使用的props，也许最好将它们合二为一。如果某些props仅与基于枚举或布尔props的某些分支相关，那么可能值得将组件拆分为多个组件。如果要为单个项目传递一个数组和一个渲染函数，那么考虑渲染props模式可能会更好。如果经常进行props传递数据，那么可能值得考虑构图模式。
  所有这些都是在考虑 React props 的 API 设计时可以提出的建议的具体示例。 但它不仅限于这些特定的示例或一般的props，还可以应用于实用程序函数和自定义钩子。最重要的是牢记这一点，尝试了解提交代码者的 API 设计并提供相应的反馈。

7. 有测试吗？

  这个问题听起来有点奇怪，因为通常会期望有测试。在审查的时候考虑这个有什么意义？ 但实际上，你会对测试被遗忘和忽视的频率感到失望。确保对新功能、修复或代码进行总体测试将对工程团队的长期帮助非常大。
  这不仅包括为新代码编写新测试用例，还包括更新相关测试用例中的旧测试用例。一般来说，至少有一个测试记录 MR 的目的和添加的代码应该是最低要求。如果不是这种情况，则可能需要根据团队处理此问题的方式提出更改请求。

8. 测试有意义吗？

  有些人认为有测试总比没有好，但我不太同意这种观点。虽然进行一般测试可能是确保代码库代码质量的第一步，但它也可能是一个非常具有欺骗性的步骤。糟糕的测试会导致错误的安全感，交付实际上不起作用的代码，并浪费时间和精力。
  当代码提交者包含测试时，请确保检查他们是否在做应该做的事情。设置、触发器和验证。它们是否取决于实施细节？设置是否正确？ 我们是否达到了适当的状态？ 所有不同部分的实现方式可能会有很大不同，但即使是最小的变化也会显着影响测试的可信度。

9. 此功能的可访问性如何？

  Web 开发的一个组成部分是我们的应用程序应该可供各种类型的用户访问。不幸的是，并非每个 Web 应用程序都针对屏幕阅读器、使用键盘进行控制或其他组进行了优化。
没有开发人员会知道如何为所有现有功能实现适当的可访问性。作为审查人，做一个记得这个主题的人，如果他们忘记实施它，提醒代码提交者，提供资源，或在必要时提出建议。

10. 我们是否更新了相应的文档？

  重构或更改现有代码时最常被遗忘是文档。无论是代码注释、文档页面还是自述文件，认为它们是最新的是一种危险的行为。
  如果知道有需要更新的官方文档、文档页面或评论，那么一定要在评论中提及它们。尤其是当代码提交者不固定在代码库的某个部分工作时，几乎不可能了解现有文档的每一个部分。但是让它们保持最新是一个团队都需要做出的努力，包括你。

写在最后

  审查同事的代码最重要的方面之一是知道要注意什么，并使它成为一个有意识的过程。不幸的是，很多开发人员并没有这样做，这让审查变得乏味、乏味且毫无意义。
  但实际上，审查可能是完全相反的，也是确保代码质量的一种极其有效的方式。 为了解决这个问题，本文提出了在审查 React 代码时应该问自己的10 个问题。这些将帮助你了解要关注的主题，为自己创建一个审查程序，并提高你的审查质量。