優秀的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通過插件方法的調用方式，自定義組件的代價極大。
#p#
合理的目錄結構
開發方式多半會影響到后續的使用方式。盡管前端腳本多半都是提供一個文件給用戶，但是在開發過程中，合理地組織自己項目的目錄結構是值得注意的。jQuery的源代碼目錄中，各個功能點都分別寫在各自的文件中，使得開發過程中編寫代碼方便。
另一方面，CommonJS的包規范還定義了以下目錄和文件：
- <span style="color: #888888;">bin doc test lib package.json</span>
分別用于存放二進制文件、項目文檔、單元測試用例、源代碼。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社區雖然活躍，佼佼者不在少數，但是整體水平的提升，還需時日，希望此文能夠幫助到一些開發者并歡迎討論。
關于作者
田永強，新浪微博@樸靈，前端工程師，曾就職于SAP，現就職于淘寶，花名樸靈，致力于NodeJS和Mobile Web App方面的研發工作。雙修前后端JavaScript，寄望將NodeJS引薦給更多的工程師。興趣：讀萬卷書，行萬里路。個人Github地址：http://github.com/JacksonTian。
原文鏈接：http://blog.jobbole.com/26101/
【編輯推薦】
