React code review 日常十问

无论你是什么语言的开发者，作为团队中的一员 code review 已是你日常工作的一部分。作为一个React开发人员也不例外。有很多资源可以教你如何优雅地写 React 代码，但是很少有文章，视频或者教程指导你Review React代码。

尽管review 同事代码是我们程序员的一项重要责任，但是这并不是许多程序员所期待的责任。比起写代码，许多程序员觉得code review枯燥无味，没有意义，觉得自己就是个‘看门’的，帮同事把把关。

就我个人而言，过去我也持有相同的观点，不太喜欢code review。但是作为一名React程序员，我在花了大量时间去code review并且深入研究后，意识到之所以不愿意code review是因为我不知道如何正确地review React代码。

通常我都是打开同事提交的代码，机械地从头到尾看一遍，添加一些我注意到的问题的评论。毫不夸张地说我不喜欢code review，并且review地质量也不高

但现在我都是有计划以及针对性去 code review。自从我开始这样做之后，code review变得不再无聊，并且我的评论得到了同事的一致好评。

我甚至喜欢看同事的代码，通过review 他们的代码，给我提供了一种了解他们编码风格，理解他们代码，询问有关代码的问题，学习新东西的方式。最重要的是为了提高代码质量，code review 提供了一个反馈机制。

本文给大家分享一些我在code review时，我经常询问自己的一些问题。如果你不确定如何review react代码，或者不知道该关注什么，那么这些问题将对你有所帮助。通过这些基础，可以使你建立自己的review 清单，并开始有意识地进行code review，同时为你的团队提供有价值的代码评论，甚至有可能开始享受code review。

1. 代码能否运行？

code review最重要地先确定代码能够正常运行。这并不是一件非常容易验证的事情。大部分情况下你将依赖于持续集成（CI）或者你自己本地骑服务验证代码能否正常运行。同时代码在合入时也要能够跑起来。

因此，你在code review时质疑代码能否正常运行没啥坏处。最差也就是你能够更好地理解代码。更好的是，你将会注意到代码提交时遗漏了一些细节，而这些细节则有助于提高代码质量。

2. 你能理解代码实现的功能吗？

通常，程序员会像代码检查工具或者静态分析工具一样review代码。他们只关注代码的实现以及是否正确地是实现。问题在于一个静态分析工具可以更快，更高效，更可靠地确保此事。尽管关注细节很好，但是如果不了解代码实际的功能，那么它不应该成为你关注的点。

无论是为了提供有意义的反馈，还是预计未来会参与此项开发，你都必须先了解代码所实现的功能。要想理解代码提交者背后逻辑，你必须先要理解代码所实现的功能。这涉及到很多东西，比如代码上下文, 代码目的以及实现。

3. 代码可读性如何？

我们不应该只满足于代码能否正常执行某个功能。这是最基本的要求，但不是最关键的。代码在合入到仓库后，需要其他人来维护的。代码的开发者不会永远使用它。甚至最初的开发者在几个月后也难以理解自己的代码。

因此，代码的可读性非常重要。可读性高的代码意味着其他开发人员能够更轻松地理解以及维护代码。举例来讲，states、条件渲染、自定义hooks, 以及如何正确地组织代码，函数以及变量命名。

代码可读性没有固定的模式，这是关于开发人员如何轻松地理解整个代码。最后代码可读性是团队的一项长期投资，并且它从code review 时就开始了。

4. 组件或hooks 是否承担了过多职责？

软件开发中一个经典的反模式是所谓的God对象。这指的是任何实例，比如对象、类或函数，它们承担了所有的职责。它知道太多，做太多，包含太多相互依赖的流。导致这个实例很难理解、使用、维护、重构，并且非常脆弱。 同样我们在开发React 代码也要避免此类事情发生。特别是react 注重于可复用性，可扩展性，单一职责原则。多留意组件以及hooks的用途，以及检查它们是否承担了过多的职责。如果是这样的话，那么建议通过抽象来解决，以防止代码库质量下降。

5. 是否有必要提取一个组件或hooks？

抽象不够会创建一个God 组件或hook, 而另一方面是过度抽象。将所有东西抽象成组件或hook, 最终也将会降低React 代码质量。

在层级结构之间引入一个额外的组件将会带来prop drilling, react 反模式，或者失去了官方推荐的组合模式。为每一个逻辑创建一个新的自定义hook，将会导致过度抽象，使得代码变得杂乱无章。

在code review 代码时，你作为代码的审阅人，同时也是导致代码杂乱无章的从犯。记住这一点并不断地询问自己这个结构是否有必要，这也使得你在不写代码的情况下为代码体系结构作出贡献。

6. 这个API是否设计的足够简单？

无论是函数参数，还是React 组件props，亦或是hook 参数，设计它们都不是一件容易的事情。特别是在定义组件props时，很容易创意个复杂且冗余的API。

如果你有两个类似功能的布尔类型UI props，那么可以考虑用一个枚举类型prop作为替代。如果两个props 总是一起使用，最好是把它们组合在一起。如果props在特定条件下（如：基于一个枚举或布尔类型prop）有效，则可以考虑拆分组件。如果为一个单独的items定义一个数组和一个render function, 最好是采用render props 模式实现。如果有太多的prop drilling, 考虑组合模式也许是值得的。

所有这些建议当你在考虑React props API 设计时，都可以提出具体的例子。但这不仅仅局限于这些特定的例子，它也适用于util 函数以及自定义hook。最重要的是牢记这一点，理解代码提交者的API设计并提供相应地建议。

7. 测试过吗？

通常你在code review 时，要求代码测试过，会觉得有点怪并觉得没有意义。但现实中你经常发现大家会忘记测试，甚至忽视测试。确保新的功能、修复，提交都经过了测试，将对你团队产生长期的帮助。

这不仅仅包括新增测试用例，同时也包括更新测试用例。一般来说最起码要有一个测试用例。但也可以根据团队实际情况来保证这次改动。

8. 测试都有意义吗？

有些人认为全面测试总比没有强，但我不这么认为。虽然测试是确保代码质量的第一步，但也可能是一个非常具有欺骗性的一步。糟糕的测试导致错误的安全感，代码无法运行，同时也浪费时间和精力。

确保提交的测试用例是否是有必要的，是否依赖于具体的实现细节，配置是否正确，是否达到了合适的状态。所有不同的分支情况都已经覆盖到了，即使是一个非常小的改动也会给测试结果带来非常大的影响。

9. 可访问性如何？

web开发的一个主要组成部分是，我们的应用程序应该对不同类型的用户都是可访问的。不幸的是，并不是每个web应用程序都针对屏幕阅读器（视障人士使用）、键盘控制（运动功能障碍使用）或其他部分进行了优化。可访问性的目的是使你的网站/应用程序在尽可能多的环境中被尽可能多的人使用，而不仅仅是那些使用高性能台式计算机的用户。极端的例子可能包括：使用较旧设备的用户（他们可能没有最新的浏览器），设备性能不高的用户（他们可能具有较慢的处理器）。

没有开发人员知道如何为现有的所有功能实现适当的可访问性。作为一名评审员，要记住这个主题，提醒提交者是否忘记实施它，忘记了提供资源，并在必要时提出建议。

10. 文档更新了吗？

重构或者更改代码时最经常忘的是更新相关文档。无论是代码注释，文档还是README，都要确保它们是最新的。

如果你发现官方文件，文档或者注释需要更新，那么一定要在code review 时提出来。尤其是当代码提交者并负责该部分代码时，那么他基本不可能了解文档的每一部分。保持文档最新需要包括你在内的团队每个成员都要为之努力。

最后

code review最重要的是要知道关注什么，并有意识地养成习惯。不幸的是，很多开发人员都不这样做，这也使得code review变得无聊、乏味和毫无意义。 在现实中，code review时确保代码质量的一种极其有效的方法。为此，本文提出了10个你应该在code review 询问的自己的问题。这些将帮助您了解code review要关注的主题，形成自己的日常review规范，并提高code review的质量。