优秀的JavaScript模块是怎样炼成的

引言:现在的JavaScript已是Web上最流行的语言,没有之一。从Github上的语言排行榜https://github.com/languages上便可看出,也是现在最为活跃的开源社区。随着Node的加入,JavaScript开枝散叶进入服务器领域,为这个语言榜的占比,也贡献了几分热度。尽管经历了Web2.0的洗礼 ,但在国内谈及开源,开源人士彷佛都当这门语言并不存在,这也意味着国内的开发中坚阶层,并无改变JavaScript以及前端过去二流形象的认识,也没意识到JavaScript现在真正的价值。历史缘由造就现在的局面,可是你并不能就此否定,一个出身很差,小时候还挺调皮的孩子,他长大后就是没有出息。本文将介绍一个优秀的JavaScript模块应该是怎样炼成的,以指望将来国内的开源社区可以涌现出更多的优秀模块。javascript

引发我写这篇文章冲动的是近期接触到moment模块时的震惊。用JavaScript写程序,一般要经历两个阶段:第一个阶段是采用一些模块来擦除JavaScript语言(跨平台)自身的问题;第二个阶段是本身写一些方法来擦除引入的模块的问题。第三个阶段才会真正进入业务开发中,前两个阶段俗称“擦屁股”。时常在第三个阶段时,我会陷回到第二个阶段,和各类模块碰撞,每每会引发一些心情上的不舒爽。而在接触到moment时,这些烦恼瞬间消散,我在心底知道为什么会如此释怀,如碰到心仪的女神。这也让我回头反思过去在使用和写模块过程当中遇到的挫折和收获,这落差让我产生了如此的冲动,此文算是一个总结,指望能在汲取优秀模块的经验中,国内开源社区可以成长起来。php

为何是模块,而不是库或者框架

在过去几年作前端的同窗多半谈论的是库,或是框架,说起库则是Prototypejs和jQuery,框架则是YUI3,Dojo、Extjs等。关于库或者框架的,对应的比喻则是大教堂和集市。在最先的时间,大教堂和集市的建设都在同步行进,具备表明意义的是YUI3和jQuery,前者Yahoo!投入许多精力,历时两代完成,后者则是集市建造的典范,由John Resig建立,社区参与。最后看看后续的反馈:html

 

大教堂未必优质

大教堂模式产出的做品,让享用者能够有一步到位的服务,无需其余。可是因为大教堂的建设过程当中承担着解决全部问题的使命,这致使它逐渐变得庞大,尽管它有着宏大而美妙的结构,像一首长长的赞美诗,任何一段均可以被唱诗班演唱得动听。可是,弱点依旧暴露出来:前端

  1. 局部的优良程度未必是最好的;
  2. 庞大的结构致使灵活度降低,升级困难。
  3. 任何一条龙服务,都不能保证每一个环节都是优异的。

小集市钻石闪烁,沙砾良多

小集市的特色是开放式建设、周期短、成本低。大多数建立出来的集市是功能简陋、品质平庸的。jQuery是一个值得玩味的现象,品质极高,可是它带来的插件市场,却体现了小集市的另外一面,大多数的jQuery插件的质量却十分低下。java

能够说小集市模式建立出来的做品,在单点上,是可以超越教堂模式做品中对应的那部分。前者缺少一个宏伟的结构,可是在微观上,它是完善的,能够随意挪移的。后者虽然具有优良的结构,但在单点上并不是优秀,这也容易让人怀疑是否其余点上也并不优秀,并且教堂式做品的一个特色则是,局部是不可移植的,非独立性的,这在YUI3中表现十分明显。git

上述对比很容易让人联想到,若是一个架构的特性具有单点可移植,可拆卸,自身极其轻量,汲取了大教堂和小集市的优势。那必将是一个全新的时代,那是一个能够DIY的时代。原有的大教堂模式因为缺失了灵活性,在迭代迅速的开发中,必将淘汰。而小集市尽管参差不齐,好在预留了选择权利给用户,而且他的开放性也预示着它的可成长性,因此还有将来可期。程序员

没错,现在这个时代已经到来。库一般是一个比框架小一个粒度的单元,模块则是比库更小一个粒度的单元。一个库可能由几个模块组成,框架则多是在几个库的基础上构建。再也不谈论库和框架的缘由是将库和框架的架构部分还给开发者,以便开发者能够根据实际业务去构建合适的解决方案。任何框架或库都只具有解决某一方面的能力,不具有普适性。当粒度下降到模块级别的时候,构建任何上层业务,能够实现按需使用。因为模块的粒度更小,因此相对库而言,更加专一,变优秀的成本更低。类比孩子在充满沙砾的海边奔跑,但很容易装满一口袋的贝壳。对于稍具慧眼的开发者而言,挑选一堆适合的模块来解决业务的问题,比使用教堂式做品或者更高效。github

这种方案由于CommonJS模块规范的影响,已经在既定事实中成型。在Node中,NPM平台(https://npmjs.org/)上13000+的模块数量能够说明这个问题。前端中因为受到历史缘由的影响,进展较慢,国内玉伯的SeaJS在推进此事,Arale是在SeaJS基础上建立了一些模块,这类模块能够很是容易迁移到其余符合CommonJS模块规范的环境中。除此以外腾讯的JX也具有SeaJS的特性,能够轻松将别的库应用到JX中,可是还不够规范。ajax

若是非得给这种模块提供方式一个名称,我以为该叫作小教堂模式,具有小集市的小,意味着这个教堂可能只提供祈祷服务,若是注册结婚,则须要换另外一家小教堂。可是这类小教堂的服务是最优质的。建立这类小教堂只比建立一个优异的小集市略费成本,换言之,优异的小集市就是小教堂,它的建立方式是沿袭小集市的开放、透明的、有既定目标的成长性的。npm

另外一个考虑是,在大部分的状况下,咱们是不须要大教堂的,现实中为了总体环境,咱们宁愿在大教堂中祈祷,可是程序设计中,咱们不会由于喜欢一棵树木,而买下整块山头,咱们几乎不喜欢任何看起来多余的部分。同时咱们也不须要小集市,咱们须要的是一个品质优良的商场。开发者是采购者,采购模块的过程既是架构的设计的过程。

前文我也提到这种小教堂的模式依然存在不理想的功能重叠、功能多余、功能缺陷、功能冲撞等问题。可谓说完美的小教堂是可遇不可求的,但一旦它完美,将再难被替换。目前阶段的JavaScript模块开发还存在着这些问题。是故,若是开发者了解如何去打造一个优秀的JavaScript模块,并乐于贡献到开源社区,这将大幅提高社区JavaScript水平,后续的开发者在作业务架构时,将具有更优质的材料来DIY更优异的产品。

炼成优秀模块的最佳实践

其实这并不算是精确的最佳实践,只是从别的模块哪里学习到的和本身过去的一些经验,仅作必定的总结。欢迎补充和讨论。

模块自身的素质要求

要写出一个优秀的模块,模块自身的素质十分重要,若是自身条件太差,成为优秀模块的几率是极小的。这些自身素质包括美好的愿景、专一的定位、名字、API设计、文档、测试等。

合理的愿景:设定既定目标

若是你打算写做一个模块,并贡献到开源社区中,并指望它是优异的,并被许多人使用的,那么为它设定一个既定目标是首要的。若是这个目标是没有意义,没有趣味的,那多半没有人使用,甚至本身开发到一半都没有兴趣继续写下去。没有理想的屌丝,注定不能成为高富帅。

对于具有众多坑爹问题的JavaScript语言而言,找到一个目标并不是难事。典型的例子如:jQuery专一解决DOM操做和Ajax、Underscore专一对象和集合的操做、QUnit和Jasmine专一BDD和TDD的单元测试、moment模块专一解决从Java那里学过来的Date的问题;拿近一些的例子,玉伯的SeaJS专一模块加载,老赵的Wind.js专一异步编程同步化来解决流程控制问题;拿一个有趣的例子,PNGDrivehttps://github.com/MadeInHaus/PNGDrive这个项目虽然没有什么实际用处,可是将文件编码为图片显示出来的方式足够有趣。

另外这个目标必须是既定的。也就意味着饼不用画为无限的,这个目标必定是能够完成的。若是目标太大,也就意味着模块自身会变复杂。jQuery兼容各类浏览器的DOM操做这个目标,在移动平台上变得没有意义,因此存在着Zepto.js这样的项目。更小的目标意味着模块自身简洁,且可以更专一,目标更容易抵达。一旦抵达目标,该模块就是稳定的,将来被替换的机会极小。

为模块或项目起一个贴切的名字

模块须要一个贴切而好记的名字。这个名字何以帮助用户最直观地感觉模块。SeaJS在起名上算是一个表率,让人很容易有海纳百川的联想,这也正是SeaJS的行为。一个好的名字可使得模块的后期推广事半功倍,并且一旦开始推广,尽可能不要换名字。

不作逾越的事

并不是每一个使用者都喜欢买一送一的感受,由于后面这个一,对于使用者而言,并不是是指望的,因此它的优良没法直观的断定好坏。无关的方法必定不要提供。评判一个模块是否完美,不是能够添加API,而是没法再减小API了。

不污染公共环境

每一个人都不喜欢公共环境被人污染。破窗效应揭示,若是一辆汽车的门窗稍有损坏,不当即修复,那么很快整辆车就会被破坏甚至偷走。 在JavaScript,公共环境包括全局变量,原型链等。jQuery和Underscore为了代码的写做方便,占用了$和_两个符号,尽管他们都提供了noConflict方法来避免冲突,可是抱怨者仍是大有人在。所幸这两个库太过于知名,几乎没有再有的库来使用这两个变量名。另外一个例子是Prototype.js库对对象进行扩展时,直接在Array、Object等原生对象的原型链上添加方法,尽管它看起来不影响,可是总有冲突的一天,而且使用者并不必定知晓原型链被改动,在他的默认上下文中,难保他也不去修改原型链。相比Prototype.js的作法,Underscore提供的方法则优雅许多,另行提供API来处理操做,而不是修改共有的原型链。

在Node和浏览器中,global和window是全局对象,若是随意放置变量到全局对象上,也容易遭到他人修改或者覆盖你变量的事情。
CommonJS提供的require、exports则十分优雅解决这个问题。谁使用,谁引入。而不是经过全局变量。在前端没有AMD或者CommonJS环境下,则是采用命名空间和闭包来解决这个问题。

不污染公共环境是模块与模块之间互相不影响的基本保证。若是引入你的模块,致使其余模块失效的事情,多半是不招人待见的。

抵制墨菲效应

有可能变糟糕的事情,它变糟糕的可能性就会变大。模块在升级,迭代的过程当中,如何避免这种糟糕的事情发生呢?答案是单元测试。当单元测试覆盖了你认为会出问题的地方,能够避免相同的错误再次发生。这是模块稳定迭代的基本保证。当我发现一个仅仅为了解决日期操做的moment模块,它为数很少的API居然具备多达7000+的断言时,十分惊讶。

过去JavaScript只作简单的事情,地位低下,因此对于JavaScript的质量保证也极少。这个思惟须要改变,一个用户在评估采用你的模块时,若是单元测试都没法看到,内心该是有多不踏实。

除此以外,还有性能测试,性能测试结果能够横向比较,也能够纵向比较,有利于感知模块的具体性能表现。

数据一般容易打动理性的人。

保持简洁

对于任意看起来复杂的事物,用户均会以为它很复杂。老赵的Wind.js(前身是Jscex)是一个想法独特的模块,但在提供的API上因为eval,以及须要引入的模块较多,让它看起来比较复杂,让用户感受潜意识里复杂,这种复杂的信号很容易变成它有问题的信号,让人心生疏远。

将能不暴露给用户看到的东西,尽可能隐藏,过多的步骤只会让用户以为麻烦和不靠谱。

职责单一

这里的反面例子来自于Require.js。若是你用过RequireJS,能够看到require方法是一个变态的设置,参数为’a’、[‘a’]、[‘a.js’]、{}他们的行为都是不一致的。这种参数类型能够随意变化是JavaScript的灵活的地方,可是函数的行为若是也发生变化,这会让人产生迷惑。适当的重载并不意味这行为也要彻底不一样。

功能过多,带来的问题的可能性也会变大,使用者在调用过程当中也会增长无形的压力。分离功能能够保持方法职责单一会是你API优秀的一部分。

编码风格

编码风格必定须要统一,并且编码风格必定不要显得外行。若是你的用户发现你的编码风格是PHP或者C#的,他们可能会产生你不是专业的这个感受。推荐贴近JavaScript社区,采用JSLint或JSHint来矫正编码风格。这有利于源代码的阅读,在不一样的人之间传递不会有不换了一门语言的感受。

API接口漂亮

API接口漂亮包含几个方面:

命名

对外API的命名须要谨慎对待,方法名太长、方法名不直观、方法名大小写不对、方法名单词太复杂都会影响到使用者的直观感觉。因为国内的英文水平高低不一,使用者碰见不认识的单词,都会形成障碍。

jQuery在方法命名上十分优秀。简短,直观,优雅。

调用

实参的传入也是考验API设计者的地方。若是须要调用者传入的参数较多,则该反思该API是否适合暴露给调用者。若是调用参数确实较多,而且支持可选项,则传入一个对象做为参数较为合适。因为对象带有明确的key,获取参数也无需一个一个检测。

$.ajax()是一个典型的例子,它支持的参数很是多,而且大多可选。因此暴露的API为$.ajax(url, obj)或$.ajax(obj)。

在JavaScript中,链式调用也是让用户较为喜好的一点。Underscore除了提供普通的API外,还支持包装对象以后进行链式调用。这让熟悉函数式编程的人,顿生亲切。

习惯

Zepto.js是一个经典的案例,它提供了与jQuery几乎彻底兼容的API,为的是照顾用户对于jQuery的熟悉。这让它能够零成本被应用到移动浏览器上。
jQuery的另外一件反面例子则是它的each方法,与原生数组的forEach方法的回调传入值次序不一样,这与习惯不一样的接口,会形成必定反感心理。 在设计API的过程当中,尽可能寻找贴合用户习惯的已有形式,这会让用户易于接受。

可扩展性

模块在开发的过程当中,能够包括有限的部分和无限的部分。有限的部分将会经过项目迭代,臻于完美。若是模块存在无限的部分,而且在有限的部分留出扩展来衍生无限,这对于模块的成长,这是一个大大的加分项。

jQuery留出$.fn来供用户扩展它,造成的影响是大量的jQuery插件涌现了出来。尽管大多数状况没有被正确使用,但不能掩盖它是一个漂亮的设计。

moment模块在它的lang部分,也提供了优雅的扩展它的部分。使得不一样地区的用户能够自定义语言的显示。

扩展性的存在,使得开源社区可以参与,可以起到抛砖引玉的效果,反过来会增进模块的功能。

使用合适的设计模式

合适的设计模式可让模块自身无瑕。不合适的设计模式则会拔苗助长。

这里的正反例子都与jQuery相关。正例子是Deferred的应用。过去ajax操做success和fail回调都必须写到$.ajax(obj)的参数对象中,可是Deferred对象使得调用更加天然:

$.get("test.php").done(function() { 
  alert("$.get succeeded"); 
});

LABjs的设计模式也十分优秀,script和wait两个用于加载和阻塞的API,经过链式调用,其乐融融:

<script>
   $LAB
   .script("framework.js").wait()
   .script("plugin.framework.js")
   .script("myplugin.framework.js").wait()
   .script("init.js").wait();
</script>

反例子则是来自jQuery插件。jQuery.fn不失为一个好的扩展点,可是有大量的jQuery插件操做的并不是DOM,却生搬硬套将方法挂靠在jQuery.fn上。另外一个例子则来自jQuery社区得意的UI组件。

$(foo).dialog('open')

这类经过传入参数,又不能获得指望的返回值的场景,并不适合操做这个组件对象,API的参数传递更是显得不三不四。若是是直接操做组件对象,则更友好一些。相比jQuery UI,YUI3的组件则优秀太多,API漂亮,组件的层次结构分明,易于扩展和自定义,jQuery UI经过插件方法的调用方式,自定义组件的代价极大。

合理的目录结构

开发方式多半会影响到后续的使用方式。尽管前端脚本多半都是提供一个文件给用户,可是在开发过程当中,合理地组织本身项目的目录结构是值得注意的。jQuery的源代码目录中,各个功能点都分别写在各自的文件中,使得开发过程当中编写代码方便。

另外一方面,CommonJS的包规范还定义了如下目录和文件:

bin
doc
test
lib
package.json

分别用于存放二进制文件、项目文档、单元测试用例、源代码。package.json文件则用于描述该包的一些包括包名、版本号、依赖等的信息,详情见http://wiki.commonjs.org/wiki/Packages/1.0。遵循规范的目录结构一般更好一点,由于你们都有同一个准则来参考,彼此更熟悉。

巨细的注解

一般用户真正须要去阅读你的代码的时候,是出现问题的时候。在开源社区,如何让发现你问题的人刚你改进代码,注释的做用功不可没。

另外,当一个用户真正是来欣赏你的代码时,若是看到Underscore这样密度的注解时(http://documentcloud.github.com/underscore/docs/underscore.html),还有拒绝它的勇气吗?

清晰明了API的文档

优秀的模块不只仅体如今代码写得好上,更多的体如今如何让用户使用时更温馨。API文档必不可少。我心目中的API文档应该详细描述方法做用、参数、返回值的。甚至还应该有demo代码伴随。

API文档能够经过jsdoc之类的注解文档来生成。也能够另起文档来写。

API文档的一个特色是应该能方便查找,能在一个页面中展示完成的,尽可能不要页面跳转或翻页。

API文档最大的做用让用户精确理解API,使得不形成误解,和清楚输入输出。

Underscore的API文档(http://documentcloud.github.com/underscore/)借用模版生成了漂亮的页面,使得查阅方便。

一见倾心的demo

相比Node,前端JavaScript模块更擅长作这件事情,尤为是UI库。男女之间首次见面的第一印象,很大程度能够决定某两我的是否会谈恋爱的几率。demo提供的形式能够影响到用户的直观体验,通常而言,用户以为越炫,可是旁边提示的示例代码越简单,越会引起用户的好奇心。若是只有代码,或者只有demo,都会在表现性上打折扣。

对于Node的模块而言,因为没有live demo的感受,尽可能展现sample代码,让用户了解到他的目标是否与模块的目标一致。不要让用户错过你的模块,也不要让你的模块错过了它的用户。

README.md

README文件承担的做用仅次于demo,无需让用户产生心动的感受,可是必定要引导用户更深度的了解你的模块,详细阅读你README的人,多半是有兴趣使用你的模块的人在作实地考察了。一个geting start入门是必不可少的,到API文档的连接也应该有。若是空落落的README,会立马有生疏感的。后期用户的心得体会等相关文章,也记得更新到README中。

模块的社区打造

话说酒香也怕巷子深。在知足成为优秀模块的基本素质要求后的首要事情是如何将模块推向开源社区,积极到社区中宣传。

放到Github开源:不只仅是代码

每个程序员都应该有属于本身的Github账号。若是你没有,不是Github的遗憾,而是你的遗憾。关于Github有什么,能够参看这篇文章:如何高效利用GitHub (http://www.yangzhiping.com/tech/github.html)。 排除掉文化上带来的好处。Github能够帮咱们托管代码,帮咱们解决版本控制的问题。它能够提供一个wiki,帮咱们存放文档。它提供Issues页面,使得别人能够为模块提出意见和反馈。提供Pull Requests页面,使得别人能够帮咱们修改代码后,供咱们合并修改。

交流平台的建立

交流平台主要用于讨论、答疑,使得模块做者和用户之间能够产生思惟的碰撞。交流过程能够不断完善模块自身的不足,造成文档。主要的形式有以下:

邮件列表

国外的社区大多采用Google Groups的邮件列表来交流。邮件列表能够将讨论发送到每个关注它的人手中。

实时交流

国外多采用IRC频道来进行此事。国内的状况,能够选择合适的QQ群来进行交流。

留言版

留言版的功能Github的issue具有了该功能。可是若是具有单独的介绍页面或者站点,集成Disqus来收集用户的反馈会是个不错的选择,由于这更符合普通用户的习惯。

版本控制

这里的版本控制不是git的版本控制。而是模块的总体版本。标注好模块的版本是分场重要的,若是用户须要升级模块,它可以获得明确的指导。前端模块中一般是在文件名上,或者文件内部写明版本。对于Node而言,写在package.json文件中。

最好可以在大版本的发布时,经过正式的新闻页面,或是邮件列表发出新闻通知,以显得版本发布的正式。

悠扬的历史:Change Log

不要小看Change log的做用,长长的,细碎的Change log能够给用户该模块历史悠扬的感受,也能让用户体会到写做该模块的过程细节。每次迭代发布的过程当中,展示给用户看当前的change log也能让用户知道改动的影响范围。若是碰巧发布了一个用户须要的方法,他会有收到礼物的感受。

选择合适的License

国内的环境中,也许你们不太关心License的问题。事实上,License的选择,会影响到用户的评估。目前只有BSD和MIT两种License可让人放心使用。对于商业公司而言,若是不是这两种License,他们须要投入更多的精力和时间周期来评估这个模块是否可用。

可是对于JavaScript社区而言,一般采用的是MIT,因此也基本没有问题。选好License,并在明显且不重要的位置代表该模块在什么License下发行。

发布到NPM中

在Node中,搞定代码后,发布到NPM中是最应该作的事。

易于得到的感受

npm install module或是一个显眼又不失素雅的Download按钮会在潜意识中让用户以为易于得到,容易集成到现有系统中。不要作了各类分享介绍以后,让用户找不到获取模块的地方。

持续集成

一个随时都能拿出钥匙,开出跑车的青年,必将被认为是高富帅。支支吾吾不能随时给出结果的人,基本是屌丝无疑。

推荐注册你的项目到travis-ci,并运行它。绿色的Passing时刻昭示该项目的可靠指数、稳定指数较高。这个小图标也能帮助你检测迭代是否出现问题。

漂亮的站点

注册一个模块名字的org域名,一套简洁明了的UI,清晰的导航,简单的demo等等。细节在先后的实践中都有说起。

标致的Logo

若是你没有任何视觉设计的天赋,厚着脸皮找你的视觉设计师同事要一枚吧,尽管它是一个锦上添花的事情,可是Logo在品牌认知上的功劳是不用质疑的。

线下分享交流

开发完模块后,必定记得分享给团队的同事,他们应该是模块的首批用户,他们给予的反馈也是最宝贵的。

另外,还能够在线下社区分享,将你的模块的推广范围从身边延续到这个城市。尽管在线下社区分享模块的机会很少,可是一旦有,不要忘记介绍本身得意的模块给他人。

分享带来的收益是明显的,有利于本身梳理对模块的认识,也能收到用户的直观反馈。

及时响应反馈

也许你的模块已经好久没有更新,可是用户仍是会发来反馈或提出问题,甚至提交pull request,请及时响应需求。若是是提出问题,说明你的文档还不够完善。若是是提出需求,则说明你最初设定的目标尚未完成。

善意营销:赏金猎人

若是有用户指出你的低级bug,或是帮你写做了模块的体验文章,这些事情都是值得模块做者有所表示的时候,由于这些用户是你的忠实用户,他们在帮你的模块成长。有所表示并不意味着要给多少钱,一些有意义的奖品或记念品更适合拉近这些用户与你之间的距离。

与兄弟社区的互动

一个社区若是太小,须要到隔壁的社区中发布一些信息让你们知晓。若是能够,不管国内仍是国外的的兄弟社区的协助推广,将会对社区运做有很大的帮助。友情连接是一个典型的方式。

模块开发者的自我修炼

模块自身的优秀加上社区的打造能够保证模块拥有不错质量和口碑。可是决定模块可否走得远,模块开发者的自身素质也十分重要,这其实模块的另外一个软素质。经历了开发阶段和社区运做阶段后,愈加展到后期,开发者的自身修炼的影响越会凸显。

忍得住寂寞&持续坚持

典型的例子是老赵对于Wind.js的坚持。在对Wind.js的开发和推广上,可谓是寂寞的。略呈偏门的异步同步化、eval、编译等工序,被误解和排斥的屡次。这是须要忍受的,若是没有持续坚持和忍住寂寞,模块就没有明天。做者的热情一旦消散,用户的热情也必然消散。

简单专一

前文的愿景部分说起到了简单专一。简单专一,不只仅是在项目初期保持,在长久发展中,也应当如此,只有简单专一方能保证小教堂的服务质量是最顶尖的。

奉献精神

模块开发和推广事实上是没有直接的经济收入的,并且还会耗费大量的时间和精力。可是开源事业的收益,其实是没法用金钱进行衡量的。而且这个过程也是自愿自发的,没有人会主动来推进你。

若是确实对经济形成影响,能够在页面上加上donate的连接。优秀的模块不会让这个donate连接的功能白费的。

幸运的是开源社区中不会缺少具备奉献精神的人,是他们在推进社区和技术发展。

演讲能力

前文提到线下分享,这对于开发者的演讲能力有更多的要求。演讲能力的高低,是在另外一个层面上提高模块的表现力,尽管这种能力不须要运行在CPU中。

文笔

模块开发者的文笔在文档的影响上是可以直观反映的。除此以外在社区推广中,文案的品质也有必定的影响。若是开发者文笔可以好到用优美的文章去传递模块的思想,这是使人愉悦和容易接受的。

人格魅力

模块的开发者应当具有良好的人格魅力,这包括人际关系、交流能力等。一个具有人格魅力和一个并不为人所知须要进一步了解的开发者,他们展示在你们面前的收效是并不相同的。后者更容易吸引他人,为模块带来更多的用户,这些人是你的用户,也是你的合做者。他们的涌入,会帮助改进模块。 关于人格魅力这个软素质,这里再也不多说,相信都了解他的重要性的。

总结

经过对最佳实践的罗列,我本身至关于重温了一遍JavaScript开源的一系列文化。而这些最佳实践部分其实都是必要条件,经过这些最佳实践,未必保证会有优秀的JavaScript模块产出。可是观察现在的那些优秀模块,他们基本上都具有这些特征。最后,JavaScript社区虽然活跃,佼佼者不在少数,可是总体水平的提高,还需时日,但愿此文可以帮助到一些开发者并欢迎讨论。

参考

http://www.infoq.com/cn/articles/how-to-create-great-js-module

相关连接

http://fex.baidu.com/blog/2014/03/fis-module/