在 Babel 的个人经历 #1 —— 一个评审数量异常之高的 PR

2017年8月11日 · 1 分钟阅读

非官方测试版翻译

本页面由 PageTurner AI 翻译（测试版）。未经项目官方认可。发现错误？报告问题 →

上周，我们在 Babylon（Babel 的解析器）中落地了对 stage-2 装饰器提案的解析器支持。如果你不了解装饰器，简单来说，装饰器提供了一种简洁的语法来影响被装饰类或类方法的定义。

JavaScript
@frozen class Foo {
  @configurable(false)
  @enumerable(true)
  method() {}

  @throttle(500)
  expensiveMethod() {}
}

关于这个 PR，最引人注目的特点之一就是它收到的评审数量

这可能是因为装饰器确实是 JavaScript 中被大肆宣传的功能之一。Angular 团队甚至考虑过创建自己的 JS 方言 AtScript，后来才决定使用 TypeScript，因为他们太喜欢装饰器了（他们常称之为"注解"）。

Well, there is more to the story. As I was recently discussing with a mentor, reviewing PRs is a tough job. Reviewing PRs is comparably as hard as solving the bug in the first place was. Apart from the technical aspect of reviewing — which is ensuring that the bug is being fixed optimally (by perhaps even getting an idea of how they would solve the issue and seeing how the submitted patch compares to their idea) — there’s another big hindrance. A reviewer has to be aware of the whole issue, the discussion surrounding it, and have familiarity with the part of the codebase that the PR makes changes to.¹

当我刚加入 Babel 时，对代码库还不熟悉，每次在聊天室提出问题几乎都能立即得到解答，这让我产生了（错误的）印象：维护者仿佛是无所不知的神明，大家都应该遵守同样不切实际的高标准。

即使熟悉代码库后，我提交 PR 时仍缺乏充分文档——我天真地认为：既然我花时间解决了问题，评审者看到代码就能立即评估，就像他们解答我的问题那样。

Eh! Very wrong. Let me just bust this myth (assuming I’m not the only one who has felt it). Even they (maintainers) won’t have all the answers at times, and sometimes you’ll have to search for yourself — and that’s how it should be.²

In open source, there are a lot of people who want to contribute, but are unable to because they don’t know how to code / they don’t know how to present PRs / they don’t know what the project wants / they don’t know what the maintainers want / a ton of other things. A lot of times you’ll find help along the way, but a lot of that is controlled by factors beyond your control.³

让 PR 被合并的喜悦不仅在于编程本身，更在于推动项目以预期的方式前进：识别项目需求并交付解决方案。

In order to merge this PR I had to find people and talk to them — people who use decorators, people who are interested in seeing an implementation of decorators, people who want to contribute to babel for decorators. After getting consensus on how to move forward⁴, I had to go through the spec and all the existing discussions surrounding it so that my understanding of the spec could be up to speed with other people.

最后——我认为这个 PR 获得大量评审的最关键原因——是让评审者能轻松掌握全局：我详细解释了所有必要背景。巧合的是，这个 PR 恰好满足了我之前提到的几个标准：

确保评审者了解完整背景（详细说明我的决策，避免他们必须阅读代码才能理解）
呈现相关讨论（说明某些决策的替代方案，便于对比选择）
清晰阐述解决策略（帮助技术评审——让评审者先了解我的思路再看代码，而非相反）

这就是关键所在！（至少我是这么认为的）。谜底就此揭开——一个评审数量异常之高的 PR¹。

附言：本文旨在分享个人经历，而非提供指南或技术分析。因此某些观点可能不具备普适性或存在争议，请结合叙述背景理解。

另请注意：若你期待 Babel 的装饰器支持，我们仍有长路要走。目前仅完成解析器部分，转换器（将代码转为功能等效的 ES5）尚未开发。但既然关键决策已定，后续进展会更加顺利。

脚注

在评审 PR 方面，我们面临人力短缺问题。这一点在我们最近的周会中也有讨论（会议记录链接）。如果您能提供帮助，欢迎加入我们的 Slack 聊天室！
我认为这种误解源于：当你刚接触项目时，导师们确实比你更了解项目细节
（举例说明）可能影响你获得帮助的随机因素包括：

在聊天室提问时，是否有处理过相同问题的成员在线
了解你疑问的人可能需要投入大量时间，他们希望给予充分关注而非简单答复
有人能准确理解你的技术背景等

我们曾因此卡壳数月，因为大量用户在使用 stage-0 时期的非标准装饰器实现。由于规范变更不向后兼容，我们不确定如何引入新规范支持而不影响现有用户。最终决定将此 PR 设为可选功能，允许用户自主迁移。

结语

Peeyush Kushwaha 是 GSoC 2017 学生。在 Twitter 关注他：@PeeyFTW！

本文原载于 Medium。更多信息请查看我们关于 Summer of Code 的首篇文章！

脚注​

结语​

脚注

结语