Skip to main content

Babel的个人经历 #1 — 一次评论异常多的 PR

· 9 min read
Peeyush Kushwaha

我们上周在 Babylon —— Babel 的解析器 —— 上为 阶段 2 装饰器规范 落地了 解析器支持。如果你不知道装饰器是什么，简单来说，装饰器就是提供一种简洁的语法来影响你装饰的类或类方法的定义。

🌐 We landed the parser support for the stage-2 decorators spec last week at Babylon — the parser for Babel. If you don’t know what a decorator is, the gist of it is that a decorator gives some concise syntax to affect the definition of a class or a class method which you decorate.

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

  @throttle(500)
  expensiveMethod() {}
}

这次 PR 的一个比较显著的地方是它收到了很多评论

🌐 One of the more remarkable things about this PR was the number of reviews it received

GitHub 上 PR 审查截图

也许这是因为装饰器确实是 JavaScript 中备受炒作的功能之一。Angular 甚至考虑过创建他们自己的 JS 版本，叫做 AtScript，但后来他们决定使用 TypeScript，因为他们非常喜欢装饰器（或者他们喜欢称之为“注解”）。

🌐 Perhaps this could be because decorators really are one of the much hyped about features in JavaScript. Angular even considered making their own JS flavor called AtScript before they decided to go with TypeScript since they love decorators (or as they liked to call it “annotations”) so much.

嗯，这件事还有更多的故事。正如我最近和一位导师讨论的那样，审核 PR 是一项很艰难的工作。审核 PR 的难度可以说和最初解决那个 Bug 差不多。除了审核的技术层面——也就是确保 Bug 被以最优方式修复（可能包括先理解他们会如何解决问题，然后看看提交的补丁和他们的想法比较如何）——还有一个很大的障碍。审核者必须了解整个问题、相关的讨论，并熟悉 PR 修改的代码部分。1

当我刚加入 Babel，对代码库还不太熟悉时，我遇到的每一个问题在我发到 Babel 聊天室后几乎都会立刻得到答复，这让我产生了（错误的）印象：也许维护者都是某种无所不知的神一样的人物，而且每个人都被期望遵循同样虚构的标准。

🌐 When I initially joined Babel, and was not-so-familiar with the codebase, every issue I encountered was almost instantly answered after I posted it in Babel’s chatroom, which left me with the (wrong) impression that perhaps the maintainers are some god-like figures who know it all and that everyone’s expected to adhere to the same fictitious standards.

即使在熟悉了代码库之后，我仍然提交 PR 时没有提供适当的文档，因为我以为自己花了很长时间解决问题并查看所有内容，但如果审查者看到代码，他们就能像回答我的问题一样立即评估它。

🌐 Even after becoming familiar with the codebase, I was submitting PRs without proper documentation under the assumption that it took me a while to solve the issue and see all things, but if the reviewers see the code they’d instantly be able to evaluate it just like they were answering my questions.

哎！完全错了。让我来拆穿这个谣言（假设我不是唯一有这种感觉的人）。就算是他们（维护者）有时候也不可能知道所有答案，有时候你得自己去查——这本来就应该是这样。2

在开源社区里，有很多人想贡献，但却做不到，因为他们不会编程 / 不会提交 PR / 不知道项目需要什么 / 不知道维护者想要什么 / 还有很多其他原因。很多时候你会在过程中找到帮助，但很多情况都是由你无法控制的因素决定的。3

让你的 PR 被合并的乐趣之一，不仅在于编程本身，还在于以项目预期的方式推动项目向前发展。而做到这一点的方式，是 somehow 识别出项目所需要的东西，并能够交付它。

🌐 One of the joys of getting your PR merged is not just the programming but somehow making the project move forward in the way it is expected to be moved forward. And doing that by somehow identifying what the project needs and being able to deliver that.

为了合并这个 PR，我不得不去找人并和他们交流——使用装饰器的人、对看到装饰器实现感兴趣的人、想为 Babel 的装饰器做贡献的人。在就如何推进达成共识之后，我还必须通读规范和所有现有讨论，以便让我对规范的理解能够跟上其他人的水平。

最后——也是最重要的部分，我认为正是这一点让这个 PR 获得了我们看到的那么多评论——就是通过解释他们需要了解的一切，让审查我 PR 的人更容易上手整个情况。碰巧的是，当时我提交的这个 PR 能够满足我之前提到的一些标准：

🌐 And finally — the most important part which I think got this PR the number of reviews that we saw — making it easy for people who’ll be reviewing my PR by explaining everything they would need to get up to speed with the whole situation. By chance, at the time the PR I made was able to satisfy some of the criteria I mentioned earlier:

  1. 确保审阅者了解整个问题（通过详细提到我所做的决定，这样他们不必一定要看代码也能弄明白）
  2. 围绕它的讨论（通过提及一些决策的不同观点，以便更容易将它们与所作出的决策进行比较）
  3. 清楚地解释我解决问题的策略（帮助技术方面的审核——这样审核者可以先了解我做了什么，然后再看代码，而不是反过来）

就是这样搞定了！（至少我觉得是这样）。谜团解开了——一个评论数量异常多的 PR¹。

🌐 And that’s what did it! (or so I think). So there’s the mystery unraveled — A PR with unusually high number of reviews¹.

附注：我想分享我个人在这篇博客文章中的经历，而不是写一篇需要遵循的指南或技术博客。因此，我的一些观点可能并不普遍适用或者存在争议，所以读者只需将其放在我叙述的经验背景下阅读即可。

另外请注意，如果你在 Babel 中寻找对装饰器的支持，我们还有很长的路要走。这只是解析器，关于转换（将你的代码转换为功能等效的 ES5）的工作尚未完成。但现在既然我们已经做出了必要的决定，事情从这里开始会更顺利了。

🌐 Also note that if you’re looking for decorators support in Babel, we still have a long way to go. This is just the parser and work on the transform (which converts your code to functionally equivalent ES5) is yet to be done. But now that we’ve made the decisions that needed to be made, things will move more smoothly from here onwards.

脚注​

🌐 Footnotes

  1. 在审查 PR 时，我们人手不足。这个问题最近也在我们的一次每周会议中讨论过（会议记录链接）。也许你可以帮我们一把。来 我们的 Slack 聊天室 支持一下吧！
  2. 我觉得这个误解来自于这样一个事实：当你刚加入项目时，导师肯定比你更了解这个项目
  3. （举例说明）一些可能影响你获得帮助机会的随机因素：
  • 如果有人在线，他和你做的是同样的事情，当你在聊天室发问题的时候
  • 知道你疑虑的人会花很多时间来处理，他们想给你个人关注，而不仅仅是给你信息
  • 能理解你处境的人，等等。
  1. 我们被卡住了一段时间，因为很多人使用了非标准的装饰器实现，而那个实现大约是在规范处于 stage-0 的时候出现的。规范中的更改不向后兼容，所以我们不确定应该如何引入对新规范的支持，同时又不对使用 Babel 的人造成太大干扰。我们最终决定，这个 PR 将作为可选项引入，让人们可以按自己的节奏迁移。

结尾​

🌐 Outro

Peeyush Kushwaha 是一名 GSoC 2017 学生。在推特上关注他：@PeeyFTW！

🌐 Peeyush Kushwaha is a GSoC 2017 student. Give him a follow on Twitter: @PeeyFTW!

这篇文章最初发布在 Medium。想了解更多信息，请查看我们关于 Summer of Code 的第一篇文章！

🌐 This was originally posted here on medium. Please check out our first post on Summer of Code for more info!