優秀的JavaScript模塊是怎樣煉成的

引言：現在的JavaScript已是Web上最流行的語言，沒有之一。從Github上的語言排行榜https://github.com/languages上便可看出，也是現在最爲活躍的開源社區。隨着Node的加入，JavaScript開枝散葉進入服務器領域，爲這個語言榜的佔比，也貢獻了幾分熱度。儘管經歷了Web2.0的洗禮 ，但在國內談及開源，開源人士彷佛都當這門語言並不存在，這也意味着國內的開發中堅階層，並無改變JavaScript以及前端過去二流形象的認識，也沒意識到JavaScript現在真正的價值。歷史緣由造就現在的局面，可是你並不能就此否定，一個出身很差，小時候還挺調皮的孩子，他長大後就是沒有出息。本文將介紹一個優秀的JavaScript模塊應該是怎樣煉成的，以指望將來國內的開源社區可以涌現出更多的優秀模塊。

引發我寫這篇文章衝動的是近期接觸到moment模塊時的震驚。用JavaScript寫程序，一般要經歷兩個階段：第一個階段是採用一些模塊來擦除JavaScript語言（跨平臺）自身的問題；第二個階段是本身寫一些方法來擦除引入的模塊的問題。第三個階段纔會真正進入業務開發中，前兩個階段俗稱「擦屁股」。時常在第三個階段時，我會陷回到第二個階段，和各類模塊碰撞，每每會引發一些心情上的不舒爽。而在接觸到moment時，這些煩惱瞬間消散，我在心底知道爲什麼會如此釋懷，如碰到心儀的女神。這也讓我回頭反思過去在使用和寫模塊過程當中遇到的挫折和收穫，這落差讓我產生了如此的衝動，此文算是一個總結，指望能在汲取優秀模塊的經驗中，國內開源社區可以成長起來。

爲何是模塊，而不是庫或者框架

在過去幾年作前端的同窗多半談論的是庫，或是框架，說起庫則是Prototypejs和jQuery，框架則是YUI3，Dojo、Extjs等。關於庫或者框架的，對應的比喻則是大教堂和集市。在最先的時間，大教堂和集市的建設都在同步行進，具備表明意義的是YUI3和jQuery，前者Yahoo!投入許多精力，歷時兩代完成，後者則是集市建造的典範，由John Resig建立，社區參與。最後看看後續的反饋：

 

大教堂未必優質

大教堂模式產出的做品，讓享用者能夠有一步到位的服務，無需其餘。可是因爲大教堂的建設過程當中承擔着解決全部問題的使命，這致使它逐漸變得龐大，儘管它有着宏大而美妙的結構，像一首長長的讚美詩，任何一段均可以被唱詩班演唱得動聽。可是，弱點依舊暴露出來：

1. 局部的優良程度未必是最好的；
2. 龐大的結構致使靈活度降低，升級困難。
3. 任何一條龍服務，都不能保證每一個環節都是優異的。

小集市鑽石閃爍，沙礫良多

小集市的特色是開放式建設、週期短、成本低。大多數建立出來的集市是功能簡陋、品質平庸的。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 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/