主小席

想说爱你不容易——致Javascript的一封信

主小席 · 2016-12-12翻译 · 1897阅读 原文链接 十年踪迹审校

关于我们开源社区,有一个问题我需要在这里着重讨论一下。

我是社区里很多开源项目(如Babel、Flow、Yarn、Lerna等)的贡献者和维护者。在社区里,我度过了许多美好的时光,同时也有过一些不愉快的体验。

因为参与社区,我受邀到世界各地参会讲演,也因此足迹遍布全球,广交天下好友。一些挚友正是通过这些开源工作才有幸得以结识。 不过恐怕不是所有的体验都能如此美好。

维护这些拥有成百上千用户的项目,意味着你要直面来自用户的诸多批评。这种感觉有时很像当一名政客。虽然有些并没什么价值,但是多数的批评还是很中肯的。然而,很多批评往往带有极度的负面情绪,令人好生难受。

一般的批评建议给人的那种感觉跟这种极端负面评价给人的感觉还不太一样。要是有人想聊一下我为我的那些项目都做过哪些妥协,我可以聊好几天;让我重新审视工作方向的问题,我也欣然接受;让我去坦然承认错误(即使确实有些难),我也是愿意的。但是,要是有人嘲笑我的努力付出,试图借此来羞辱我,或者,有人极力想贬低我的工作成果的话,这就真惹毛我了。我表示后果很严重。


举个例子: Babel 6项目启动的时候,有一个计划了很久的API改动,我们把其中一个隐式行为改成显式行为。这次改动涉及到多处输入修正,在发布Babel 6之前并没有人提出异议。此前几个月,我们曾就此次改动目标进行了内部交流,并且在社区里征集过反馈意见。

然而等到正式发布之后没多久,就有文章陆续出来指手画脚。有的说,“Babel 6就是一次软件设计失败的教训”,也有的说,“Babel项目组毁了web平台”。甚至有的人在线@我,骂我白痴。此外,一大波讨论“JS疲劳”的文章也都在这个时候纷纷涌现。 这是来自Reddit网站文章的一个截图,名字叫“Web开发之殇”。

那段时间我感觉自己每天都在经受着各种批评和攻击,来告诉我这次搞得有多砸。

我们在这个项目上曾经殚精竭虑地工作,但这已经不能成为支撑我们继续付出的理由了。反正我是不想再在Babel上花费精力了。本来在开源社区上做的这些事让我感受到很多前所未有的欢愉,但是这些极端的负面评价,让我对每天的工作都感到生不如死。

“愤怒的反馈如潮水般向我涌来,每天我都能收到来自各方的狂轰滥炸,说我做的有多烂。累觉不爱,我已经不再关注和解决问题了。” — "这是Babel 6发布几个月之后我在Reddit上发的状态"

如果开源项目的维护者发生懈怠,那么对于任何开发社区来说都是个大的问题。假如每过几年社区里的人都会被几个新工具折腾到不行,那么社区应该做的是帮助大家来度过难关。因为问题不解决的话,这类批评到最终伤害的还是社区本身。

必须承认,我们的工具是有很多的问题。但是,你不能光靠嘴炮去攻击那些贡献最多的人,你自己为什么不过来帮忙解决问题?解决问题不见得比你到处喷多花多少力气,但是大部分人还是宁可动嘴也不愿意动手。


下面我还想再说说这篇题为 “Angular 2弱爆了”的文章 文章截图

不说别的,光是标题就充满了火药味。当然,作者是希望强调一些问题所在。但是,他真的觉得我们维护人员看见这种标题之后还愿意点进去看吗?更不要说去定位解决问题了。

文章接下来列举了他们在使用Angular 2的过程中遇到的一系列问题。整篇文章的风格就是几个诱导点击的大标题,加上一些暴走式的吐槽。但就是死活不讲清楚问题到底是什么。

还有些/r/javascript上的提问,都是在对上面文章的行为进行效仿和辩护,令人不忍卒读。

这类不具有任何良性导向的文章简直毫无营养。就是网络上一帮人聚在一起泄愤,喷完了这一家喷下一家。

Angular小组聚集了很多奇人,他们头脑聪明,具有相当丰富的社区经验。我相信他们肯定能处理好的。

然而,并不是每个人都能做到愈挫愈勇。因为来自心灵的创伤是不会被磨平的,只会越积越深,尤其是对承受能力还比较弱的新人。

我不是说我们不接受批评,也不是说我们不应当开源工具。我写下这篇文章,不是因为我是Angular 2的死忠粉。(我已经不做UI工作很多年了,即使是当初做UI的时候,Angular 2也不是我的菜。)

前几周我确实有用Angular 2,因为我觉得了解别人在技术层面的决策并且在第一时间体验是一件很有裨益的事。

作为一名经验丰富的前UI从业人员,我从我的经验角度出发,分享一些个人看法:

  1. Angular 2较上一版本有许多改动,它的设计理念很前卫,很多设计思想还未在社区里被广泛知悉。这会导致陡峭的学习曲线吓退很多用户。

  2. 模板引入了许多紧凑型语法,让人不能一眼看明其含义。尽管这些语法绝对符合语义逻辑,但是语法习惯确实让人感到无所适从,有时还容易导致开发者的过度理解。

  3. 项目文档试图让读者快速领会并掌握所有的内容。然而欲速则不达,因为要学的东西实在太多,读者很难及时消化。另外,对应的示例程序也没能做到有的放矢。(和第1点原因有关)

  4. 还是项目文档的问题。文档里引入了好多说服力不是很强的新概念。如果要引入新概念,却又不能给出合理的解释来说明它为什么好,那基本是很难让人信服的。(也和第1点原因有关)

关于Angular 2的问题我还能举出一大堆,不过我只是想用上面的例子来表明:像这样提意见的方式,才是有建设性的,而不是靠发牢骚、抱怨和攻击就能解决问题。

上面每一条意见反馈,都能给开发者指明问题所在(第一条除外,第一条是用来给后面几条做铺垫的)。我是站在一个友好用户的角度,从提升项目质量的目的出发,提出这些意见的。

喷或不喷其实都不难做到。像我这样,把注意力放在遇到的问题上并努力去寻根溯源,才是应该做的事。我更加注重能够有效提升用户体验方面的改进,所以我提出的意见多是针对文档的,至于其它方面我也没太多资格评论。要知道,提建议须做到得体、得理,可不是一味的发泄情绪了事。


做一名程序员有时候真心不爽。你会因为程序不能按照你想要的方式执行而感到抓狂(生活亦然)。无论是在软件层面还是在社交生活层面,不同的人有不同的方式来应对。

我能够理解这些愤怒地来源。人们会因为遇到麻烦而感到不爽,人们也会因为不能成为开源项目的决策者而愤愤不平,同时这些开源工具关乎使用者们的工作大事,有点情绪是很正常的。

我所鄙视的是一部分人,他们肆意攻击那些能够给予其帮助的人。我鄙视那些不寻求积极解决办法,只知道在网上泄愤的脑残。

我得承认,我也有过N多次因为宣泄不良情绪而感到自责。愤怒和沮丧的威力不容小觑。带有这些负面情绪的交流,效果通常不会太好。每次发泄完我都会感到后悔。因为这个我也没少强迫自己跟别人道歉。

在就某一问题进行探讨的时候,人们往往容易为愤怒情绪寻找借口。人们会觉得,我之所以这么激动,是因为我恨铁不成钢,而且我的出发点是好的。

但是在社区里我们应当杜绝这种想法。


想解决问题,真心没必要搞个文章或者跑到人家的Twitter上去喷。但是,貌似社区里的很多人更愿意助纣为虐,谁骂得凶就支持谁。

真是看热闹不嫌事大。你们跑去给这些喷子的留言或者文章点赞,恰恰助长了他们的嚣张气焰。每当大家一窝蜂地去评论作者发言的时候,都无形中成为了攻击者们的帮凶。一篇有1000个赞并附带600个评论的喷子文章,堪比最厉害的伤人利器。

即使是那些头脑清醒、积极态度或者心存善意的人,对这种行为也没有表现出怒而制止的意思。

那些纵容支持这些恶行的子社区,项目维护者们往往都避而远之,毕竟谁都不想成为网络暴力的下一个受害者。

这种谩骂攻击往往持续长达数周甚至数月,最后都以那些能从根本上解决问题的人的退出而告终。这是对社区来说是最坏的结果——维护者们离开,项目宣告终结。

Babel项目由一个新组建的团队花费将近整整一年的时间,才得以恢复维护。这期间全倚仗了Henry ZhuLogan Smyth的辛苦付出。

我一年来对项目最大的贡献是为其添加了Guy Fieri的ASCII字符集,结果被某些人评价为“极不专业”。他们质问道:“以后还怎么让我们相信这样一个团队?”。好吧,还得再冷静一下。


好多诸如/r/javascript或者Hacker News这样的“子社区”,他们似乎更青睐负面新闻。

前面提到过,这几年我在社区有幸结识了很多开源项目的维护者。我见过的维护者没有几千也有几百。几乎任何一个有着上千GitHub大牛在维护的项目,我至少都见过其中的一两位。

我与这些大牛们谈笑风生,几年来收集了不少意见和建议。

他们经常建议我不要上/r/javascript或者Hacker News这样的“子社区”,因为这些地方全是一帮不知所云的SB,还有一帮无所不喷的脑残,比粪坑和垃圾堆有过之而无不及。

我听的最多的一句话就是:“千万别让这帮low逼拉低你的下限,不值当”。

全赖这帮没有做人底线的喷子管不住自己的嘴,那些最有可能定位疑难问题的人,最后都被社区给逼走了。

这样下去可真不行,不能继续鼓励这种风气。就算不是为了维护者们,也得为我们自己着想。如果继续让这种不良风气横行,最后吃亏的还是我们自己。

我们得找出来那些能切实解决问题的文章,这些文章才是真正能给社区带来正能量的。要鼓励有正向产出的交流,抵制负能量的言论,让无谓的争执没有滋生的土壤。

我们要着眼于解决问题、互相帮助、交流思想,共建和谐美好社区。开源社区就是具有这样开放的特质————人人都是主力军。是贡献还是破坏,完全取决于我们自己。

这就是社区如今面临的现实问题。现在的我们是选择为自己搭建向上的天梯还是选择自掘坟墓自甘堕落,无须我多言。 James Kyle