网站建设案例行情,企业官网建设的重要性,江苏省两学一做网站,做美剧盗版网站引言#xff1a;如今的JavaScript已经是Web上最流行的语言#xff0c;没有之一。从Github上的语言排行榜https://github.com/languages上即可看出#xff0c;也是如今最为活跃的开源社区。随着Node的加入#xff0c;JavaScript开枝散叶进入服务器领域#xff0c;为这个语言…引言如今的JavaScript已经是Web上最流行的语言没有之一。从Github上的语言排行榜https://github.com/languages上即可看出也是如今最为活跃的开源社区。随着Node的加入JavaScript开枝散叶进入服务器领域为这个语言榜的占比也贡献了几分热度。尽管经历了Web2.0的洗礼 但在国内谈及开源开源人士似乎都当这门语言并不存在这也意味着国内的开发中坚阶层并没有改变JavaScript以及前端过去二流形象的认识也没意识到JavaScript如今真正的价值。历史原因造就如今的局面但是你并不能就此否认一个出身不好小时候还挺调皮的孩子他长大后就是没有出息。本文将介绍一个优秀的JavaScript模块应该是怎样炼成的以期望未来国内的开源社区能够涌现出更多的优秀模块。 引起我写这篇文章冲动的是近期接触到moment模块时的震惊。用JavaScript写程序通常要经历两个阶段第一个阶段是采用一些模块来擦除JavaScript语言跨平台自身的问题第二个阶段是自己写一些方法来擦除引入的模块的问题。第三个阶段才会真正进入业务开发中前两个阶段俗称“擦屁股”。时常在第三个阶段时我会陷回到第二个阶段和各种模块碰撞往往会引起一些心情上的不舒爽。而在接触到moment时这些烦恼瞬间消散我在心底知道为何会如此释怀如碰到心仪的女神。这也让我回头反思过去在使用和写模块过程中遇到的挫折和收获这落差让我产生了如此的冲动此文算是一个总结期望能在汲取优秀模块的经验中国内开源社区能够成长起来。 为什么是模块而不是库或者框架 在过去几年做前端的同学多半谈论的是库或是框架提及库则是Prototypejs和jQuery框架则是YUI3Dojo、Extjs等。关于库或者框架的对应的比喻则是大教堂和集市。在最早的时间大教堂和集市的建设都在同步行进具有代表意义的是YUI3和jQuery前者Yahoo!投入许多精力历时两代完成后者则是集市建造的典范由John Resig创建社区参与。最后看看后续的反馈 大教堂未必优质 大教堂模式产出的作品让享用者可以有一步到位的服务无需其他。但是由于大教堂的建设过程中承担着解决所有问题的使命这导致它逐渐变得庞大尽管它有着宏大而美妙的结构像一首长长的赞美诗任何一段都可以被唱诗班演唱得动听。但是弱点依旧暴露出来 局部的优良程度未必是最好的庞大的结构导致灵活度下降升级困难。任何一条龙服务都不能保证每个环节都是优异的。小集市钻石闪烁沙砾良多 小集市的特点是开放式建设、周期短、成本低。大多数创建出来的集市是功能简陋、品质平庸的。jQuery是一个值得玩味的现象品质极高但是它带来的插件市场却体现了小集市的另一面大多数的jQuery插件的质量却十分低下。 可以说小集市模式创建出来的作品在单点上是能够超越教堂模式作品中对应的那部分。前者缺乏一个宏伟的结构但是在微观上它是完善的可以随意挪移的。后者虽然具备优良的结构但在单点上并非优秀这也容易让人怀疑是否其他点上也并不优秀而且教堂式作品的一个特点则是局部是不可移植的非独立性的这在YUI3中表现十分明显。 上述对比很容易让人联想到如果一个架构的特性具备单点可移植可拆卸自身极其轻量汲取了大教堂和小集市的优点。那必将是一个全新的时代那是一个可以DIY的时代。原有的大教堂模式由于缺失了灵活性在迭代迅速的开发中必将淘汰。而小集市尽管良莠不齐好在预留了选择权利给用户并且他的开放性也预示着它的可成长性所以还有未来可期。 没错如今这个时代已经到来。库通常是一个比框架小一个粒度的单元模块则是比库更小一个粒度的单元。一个库可能由几个模块组成框架则可能是在几个库的基础上构建。不再谈论库和框架的原因是将库和框架的架构部分还给开发者以便开发者可以根据实际业务去构建合适的解决方案。任何框架或库都只具备解决某一方面的能力不具备普适性。当粒度降低到模块级别的时候构建任何上层业务可以实现按需使用。由于模块的粒度更小所以相对库而言更加专注变优秀的成本更低。类比孩子在充满沙砾的海边奔跑但很容易装满一口袋的贝壳。对于稍具慧眼的开发者而言挑选一堆适合的模块来解决业务的问题比使用教堂式作品或者更高效。 这种方案因为CommonJS模块规范的影响已经在既定事实中成型。在Node中NPM平台https://npmjs.org/上13000的模块数量可以说明这个问题。前端中由于受到历史原因的影响进展较慢国内玉伯的SeaJS在推动此事Arale是在SeaJS基础上创建了一些模块这类模块可以非常容易迁移到其他符合CommonJS模块规范的环境中。除此之外腾讯的JX也具备SeaJS的特性可以轻松将别的库应用到JX中但是还不够规范。 如果非得给这种模块提供方式一个名称我觉得该叫做小教堂模式具备小集市的小意味着这个教堂可能只提供祈祷服务如果注册结婚则需要换另一家小教堂。但是这类小教堂的服务是最优质的。创建这类小教堂只比创建一个优异的小集市略费成本换言之优异的小集市就是小教堂它的创建方式是沿袭小集市的开放、透明的、有既定目标的成长性的。 另一个考虑是在大部分的情况下我们是不需要大教堂的现实中为了整体环境我们宁愿在大教堂中祈祷但是程序设计中我们不会因为喜欢一棵树木而买下整块山头我们几乎不喜欢任何看起来多余的部分。同时我们也不需要小集市我们需要的是一个品质优良的商场。开发者是采购者采购模块的过程既是架构的设计的过程。 前文我也提到这种小教堂的模式依然存在不理想的功能重叠、功能多余、功能缺陷、功能冲撞等问题。可谓说完美的小教堂是可遇不可求的但一旦它完美将再难被替换。目前阶段的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 UIYUI3的组件则优秀太多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/转载于:https://www.cnblogs.com/slogeor/p/4340876.html
