柏林纪行（上）：整体感受-CSDN博客

受集团赞助，参加了今年五月在柏林举行的 JSConf EU。另外 Node.js 社区趁着欧洲参会的人多以及考虑到柏林靠近 V8 团队大本营慕尼黑，在 JSConf 前两天在附近举办了一次Node Collaboration Summit和一些别的活动，作为 Node Core 的 collaborator 我也一并参加了，以下是个人的一些总结。

传送门：

整体感受：阿里与中国开发者在国际社区与标准制定过程的缺席

平行世界

在柏林的几天我和许多认识不认识的人交谈下来，最大的感受就是阿里，或者说中国的开发者在国际社区几乎没有什么存在感。几乎每个和我第一次见面的人在得知我在阿里工作，住在中国的时候，都表示好奇为什么中国的程序员好像活在另一个宇宙里。这里说的中国程序员，特指“土生土长，在中国公司工作的程序员”。从很多人的说法里听下来，我们就像一股神秘的东方力量，虽然人多势众，但是很少出来和国际社区的人交流。比如说，虽然每个人都听说过阿里，但是只在新闻里听说过，见过我们大 boss 的各种采访，只有极少数人见过阿里的程序员，有些人虽然听说过阿里的开源项目，但是点进去一看都在用中文讨论 issue 和写 commit，注释里可能还有很多中文，于是就默默点叉了。大家见过和交谈过的中国程序员绝大部分都是外籍或者在外工作的，所以对在中国公司工作的土生土长中国程序员感到十分好奇。一部分人知道墙的存在还能多少理解一些，其他人都感到十分困惑，对于很多人来说我就是第一个活生生出现在他们面前跟他们说话的“real Chinese” = =。这其中还有不少人是经常到世界各地开会，见多识广的，于是就更加奇怪了。

按照个人的经验，其实在 GitHub 上活跃的中国程序员还是很多的，但是实际参与到大型开源项目的日常维护，经常开 PR 和帮助维护 issue tracker，参加线上下会议的就很少了，只是偶尔出现的话这些项目里的人一般不会在意对方本人是怎样的人，没有交谈过一般也不知道真实姓名和来自什么地方，所以自然也就不知道对方其实是中国程序员了。国内对“自己创建的开源项目”一般更上心，但是据我观察好像这样的自己创建开源项目很少会有国际社区的人参与进来，一个主要的原因是这些项目大部分第一工作语言都是中文，让大部分不会中文的人望而却步，所以最后依然是两个平行世界。作为对比，像 JS 社区里比较知名的 Vue.js 虽然作者是华人，但是不在国内工作，第一工作语言也是英文，最开始也是在国际社区推广成功的，后来也在中文社区做了很多努力，所以算是比较罕见的在两个世界都有存在感的项目。

然而开源社区里，“维护者”总是比“创建者”要多得多，拿我比较熟悉的 Node.js 社区来说，Node.js Core 的大多数维护者都是最近几年才参与到项目里来的，npm 上很多热门模块的维护者也不是作者本人，这些有影响力的项目日常的 issue triage，code review，代码维护，新功能实现，版本发布，技术决策，很多都已经和原作者没什么关系了，社区活动大部分也都是承担日常工作的维护者们在互相沟通，而这样的维护者中确实很少有活跃的中国程序员，也难怪他们会有这样的疑问了。我曾经考虑过语言障碍是不是造成这个现象的一个原因，但实际上我接触过的很多维护者母语都不是英语，即使拿亚洲国家来说，隔壁日本的程序员在国际社区活跃的也不少，而日本程序员的平均英文水平似乎也并没有比中国高特别多，只要不影响理解大家都是可以沟通的。另外还有好几个人跟我提过的一点是，似乎只有中国人会在默认用英语的 issue tracker 上直接用中文开 issue，其他非英语国家的人都不会这样，他们都很好奇为什么，然而其实我也不知道原因……

回来和其他同事讨论这个现象的时候，还想到了一点，就是我们喜欢看自己的某些项目具备了基本的英文文档，或者我们有某几个在国际社区比较活跃的开发者，就以为其他国家的人应该会注意到中国项目和中国开发者的存在，所以会觉得他们说看不到中国人有些奇怪。然而我们的项目仅仅是无数个来自不同国家的项目里的几个项目，我们的开发者也不过是无数个来自不同国家国家开发者里的几个人，每个人的关注范围都是有限的，注意不到这几千几万分之一的来自中国的活动，其实也不是很难理解。换句话说，就是数量虽然不是没有，但是太少了，而且缺乏现象级的活动，因此还不到能让大多数人察觉到的地步。

尬聊

另外据我观察，似乎国内的程序员在被公司派出去参会的时候都不怎么和非华裔的人搭讪，比较喜欢找同样是来自中国的人搭话（我遇到过一些其他中国公司的人，他们似乎都倾向于找亚裔说话，而且发现对方是华人会很快切换到中文），所以造成了即使我们有人出国参会，结果非中国程序员依然不认识中国的程序员的状况……不过根据我在国外留学的朋友的说法，似乎这个情况在留学生里也是很常见的……

P.S. 我第一次出国开会的时候也不会主动找人聊天，不过被几个认识的人带着尬聊和被几个人尬聊之后，就学会套路了，基本就是看到落单的人自己刚好又很闲的话，就凑上去说 Hi I am xxx，对方这个时候会回 Hi I am yyy, 然后两边握手说一下 nice to meet you，接下来就是 where do you come from, where do you work, what do you work on 三件套就可以开始瞎聊了。如果是因为某些因素见过好几次面或者一起参与过几次讨论，但还没有直接说过话的，开头加句 Have I introduced myself to you?或者 I don't think I have introduced myself to you就可以。其实和国内开会搭讪也没什么区别，另外因为我是女的所以和女程序员搭讪有 buff，所以我比较喜欢找女程序员搭讪，开会中途吃饭拼桌的时候也是和旁边的人边吃边聊的好机会。除了这个尬聊的方式以外，在有第三方共同认识的人在场的情况下也可以很快认识人，如果第三个人不主动介绍你们认识，在交谈的间隙说一句I don't think we have met然后报上名字伸手即可，当然最快的就是以前在 github 一起 code review 过的人直接报 github id 就一见如故了……

午餐时间，尬聊的机会

Community Area，尬聊机会x2

JavaScript 标准过程中的缺席

除了在社区活动和开源项目中的缺席以外，还有一些人好奇的一点是，中国公司在标准制定组织里似乎没有什么存在感。有个德国人告诉我，他曾经问 Branden Eich（JavaScript 之父）为什么 TC39 （制定 JavaScript 标准的组织）里没有中国公司，Branden Eich 的回答是他感觉中国人似乎对标准不感兴趣。这让那个人感到相当诧异，他问我为什么像阿里这样广泛使用 JavaScript 的公司，会对 JavaScript 标准的制定和决策不感兴趣呢？然而这个问题，我也给不出一个看上去比较合理的答案……

因为我是 Node.js CTC（Core Technical Comittee）的提名成员，所以也参加了 Node.js Collaboration Summit 后 Google 撮合的一次 Node.js CTC + TC39 + V8 团队 + npm 的人 + IBM 的人 etc. 的聚餐，刚好有跟 TC39 的 Daniel Ehrenberg 聊了一下，在我简单介绍了一下我的工作之后，他想知道阿里人对 JavaScript 标准的现状和进行中的 proposal 的看法。在钉钉和一些同事讨论过后，后来 JSConf EU 有一个 TC39 的 Panel，结束后 TC39 的几个人在 Google 的展台继续交流，刚好上台的 TC39 成员里 James Snell 也是我平时交流比较多的 Node.js 社区的核心成员，于是我就过去聊天，把我总结的一些反馈和思考告诉了他们。

TC39 在台上的 Panel，左一的 James 和左四的 Myles 都是 Node.js CTC 的成员。左二是 Domenic Denicola 也经常和 Node.js Core 有合作，左三是 Daniel Ehrenberg，左五是一个在微软工作参与维护 moment.js 和 Date API 的成员。

在和 Daniel 和 James 交谈的时候我们聊到了最近 Node Core 里几个关于 Promise 的 PR，James 的感觉是虽然 async/await 已经落地了，但是在 Node 的用户里教育和推广离开 callback style 还需要时间，于是我向他们介绍了一下 generator 在 async/await 出现前已经在阿里的生产环境使用了很多年，内部的后端代码基本没有什么人用 callback 了，基础库的 API 上基本不是 promise 就是 generator，内部的定制框架基本都不基于 express 而是 koa。他们对国内几乎完全不同的风向很惊讶，根据 Daniel 介绍，V8的generator 当初是 Bloomberg 赞助他现在的公司的 Igalia 的 Caitlin Potter 实现和帮助推进标准的，就是因为 Bloomberg 和我们一样内部很依赖这种 generator 的用法（P.S. 我在会场居然碰到了以前在中大认识的师兄，他就在伦敦为 Bloomberg 工作，据他介绍Bloomberg 内部有一个 V8 的 fork，里面有很多私有的扩展，这点有一点类似 alinode 的前身的情况）。Daniel 现在正在负责推进的一个标准是任意精度的整数，这让我想起 alinode 其实内部也曾经有一个为蚂蚁的业务需求添加了 BigNumber 的 fork，而且阿里内部的前后端 JavaScript 代码确实遇到过类似用 Number 做 ID 的类型结果遇到精度问题，需要抓紧升级的情况。但我们基本都是自己去寻找曲线救国的解决方案，并没有想到去 TC39 推进标准，从长远角度解决问题，也没能 Igalia 一样作为第三方协助推进 JavaScript 引擎上游做实现，阿里作为 JavaScript 的使用大户，虽然在很多方面受到 JavaScript 标准的影响，但在 JavaScript 标准和实现上的参与还是太少，也难怪别人会觉得奇怪了。在我跟他们介绍阿里 JavaScript 和 Node.js 技术应用的一些情况（包括 YunOS，enclose 这些比较罕见的应用）的时候，他们表示，为什么你现在才出现，我们根本不知道还有一个大公司在这样用 JavaScript = =！我只能回答其实我去年才毕业，在阿里正式工作不到一年，阿里和国内业界的很多情况我也是才了解没多久……= =|||

或许我们在标准制定和实现上的缺席有一点是因为，我们内部推广一个新东西一般比在社区推广高效的多，TC39的标准制定过程十分漫长，中间有很多无比枯燥的文案细节要讨论，无数画风不太友好的会议要开，虽然 JavaScript 引擎实现新特性也是相对效率比较高的（除了要经常跟进proposal 的变动，但毕竟基本都是写代码，不怎么需要动嘴皮子），但是许多需要 runtime 配合实现或者推广的特性还是会很长时间都无法落地。比如 Promise 在 Node.js API 上的整合，纠缠了好几年都没有落地，中间出现过许多个 PR，最后都会被无休无止的论战淹没，以前成立过的 Promise Working Group 现在也不活跃了，最近几个为 Node 添加的 PR 也是争议不断。这样有争议性的月经话题纯粹由社区的志愿维护者去推进，很容易最后大家都觉得口水战太久浪费彼此的时间，结果一次又一次不了了之（P.S. 从柏林回来之后为 Node.js Core API 添加 Promise 抽象的 util.promisify() 终于合并了，感谢耐心惊人的 Anna，她大概是我见过的脾气最好的人之一 = =）。虽然我们内部对 Promise 和 async/await 存在实际需求，但是毕竟在 Node.js Core 没有直接支持的情况下，我们用 npm 模块加上 co + generator 也能达到类似的开发体验，自己也有其他需求在身，对于推动社区和标准落地这种容易吃力不讨好还特别耗费时间的事情，自然就没有十分的动力了。

我们组因为工作内容的原因，偶尔会向 V8 交一些 patch，而向 Google 的开源项目提交 patch 需要签署 CCLA，中间的过程十分漫长，需要联系法务做一些不在程序员认知领域的手续。到我提交 patch 的时候我们组已经把坑给踩过了，虽然时隔略久法务也忘了怎么为新成员授权，不过通过四处查阅文档一两天后也解决了手续问题。然而看当初第一次签署协议的邮件记录了解流程的时候，还是对整个过程的曲折程度感到惊讶，幸好我授权的时候原来接口的法务还在，如果当初的法务离职了，没有交接好这个十分低频的工作，估计就远远没这么顺利了。相比之下，仅仅是内部 fork，不提交 patch 回去的话想怎么改就怎么改，或许这也是我们倾向于内部造车而不是提交反馈回上游开源社区的一个原因。当然这种东西法务也是一回生两回熟，Intel 和 IBM 这样四处参与开源项目的公司对这种手续就已经驾轻就熟了，以后的情况还是比较乐观的。

另外一点与国外大公司不同的是，在对待标准化进行中的 JavaScript 新特性的时候，我们大多数人还处在只看 proposal 表面而不去关心细节，注意不到其中可能和自己的实际需求完全脱节的坑的阶段。相比之下 Google 这样技术布局更广的公司对 proposal 的细节关注更高，不会只对一个 proposal 看似美好的表面欢呼雀跃，而是会去认真挑刺，对于他们关心的 proposal，如果发现和实际需求不符合的情况他们会直接进行阻拦，宁可什么都没有也好过让一个有缺陷的特性进入 JavaScript 的标准覆水难收，就连自家同事做 champion 的 proposal 可能也照怼不误，比如 Object.observe，可取消的 Promise 都是这样夭折的。一个论点是，只要实际需求足够强烈，proposal 们都是会以更好的形态卷土重来的，所以阻拦一个特性的实现并不会造成世界末日。包括当年的 ES4，最近几年被不少人在 TypeScript 的风潮下发现当成遗珠，觉得微软和雅虎当年的阻拦似乎显得有些无理取闹，但事实上参与 ES4 制定的很多人其实是庆幸 ES4 最终没有落地的，因为 ES4 的很多想法表面上看似美好，事后具体去深究他们写出来的草案细节，会发现其实还有很多严重缺陷，这是许多普通的应用开发者光看各种 proposal 的概述，不去直接翻阅 ecma-262 的情况下不会注意到的，只有整天关心茴字有几种写法，不断咬文嚼字的标准制定者们才会感到后怕。当然，某些阻拦新特性的理由可能显得有些杞人忧天，为了一点小事伤了大计，然而一个未落地的新特性到底会不会因为一点细节上的 bug 在开发者社区造成严重的负面影响，是没有人能给出确切答案的，毕竟没有人能够预测未来，只能说塞翁失马，焉知祸福了。