優(yōu)秀的JavaScript模塊是怎樣煉成的
引言：如今的JavaScript已經(jīng)是Web上最流行的語言，沒有之一。從GitHub上的語言排行榜https://github.com/languages上即可看出，也是如今最為活躍的開源社區(qū)。隨著Node的加入，JavaScript開枝散葉進入服務(wù)器領(lǐng)域，為這個語言榜的占比，也貢獻了幾分熱度。盡管經(jīng)歷了Web2.0的洗禮 ，但在國內(nèi)談及開源，開源人士似乎都當這門語言并不存在，這也意味著國內(nèi)的開發(fā)中堅階層，并沒有改變JavaScript以及前端過去二流形象的認識，也沒意識到JavaScript如今真正的價值。歷史原因造就如今的局面，但是你并不能就此否認，一個出身不好，小時候還挺調(diào)皮的孩子，他長大后就是沒有出息。本文將介紹一個優(yōu)秀的JavaScript模塊應(yīng)該是怎樣煉成的，以期望未來國內(nèi)的開源社區(qū)能夠涌現(xiàn)出更多的優(yōu)秀模塊。
引起我寫這篇文章沖動的是近期接觸到moment模塊時的震驚。用JavaScript寫程序，通常要經(jīng)歷兩個階段：第一個階段是采用一些模塊來擦除JavaScript語言（跨平臺）自身的問題；第二個階段是自己寫一些方法來擦除引入的模塊的問題。第三個階段才會真正進入業(yè)務(wù)開發(fā)中，前兩個階段俗稱“擦屁股”。時常在第三個階段時，我會陷回到第二個階段，和各種模塊碰撞，往往會引起一些心情上的不舒爽。而在接觸到moment時，這些煩惱瞬間消散，我在心底知道為何會如此釋懷，如碰到心儀的女神。這也讓我回頭反思過去在使用和寫模塊過程中遇到的挫折和收獲，這落差讓我產(chǎn)生了如此的沖動，此文算是一個總結(jié)，期望能在汲取優(yōu)秀模塊的經(jīng)驗中，國內(nèi)開源社區(qū)能夠成長起來。
為什么是模塊，而不是庫或者框架
在過去幾年做前端的同學多半談?wù)摰氖菐欤蚴强蚣?，提及庫則是Prototypejs和jQuery，框架則是YUI3，Dojo、Extjs等。關(guān)于庫或者框架的，對應(yīng)的比喻則是大教堂和集市。在最早的時間，大教堂和集市的建設(shè)都在同步行進，具有代表意義的是YUI3和jQuery，前者Yahoo!投入許多精力，歷時兩代完成，后者則是集市建造的典范，由John Resig創(chuàng)建，社區(qū)參與。最后看看后續(xù)的反饋：
大教堂未必優(yōu)質(zhì)
大教堂模式產(chǎn)出的作品，讓享用者可以有一步到位的服務(wù)，無需其他。但是由于大教堂的建設(shè)過程中承擔著解決所有問題的使命，這導致它逐漸變得龐大，盡管它有著宏大而美妙的結(jié)構(gòu)，像一首長長的贊美詩，任何一段都可以被唱詩班演唱得動聽。但是，弱點依舊暴露出來：
1、局部的優(yōu)良程度未必是最好的；
2、龐大的結(jié)構(gòu)導致靈活度下降，升級困難。
3、任何一條龍服務(wù)，都不能保證每個環(huán)節(jié)都是優(yōu)異的。
小集市鉆石閃爍，沙礫良多
小集市的特點是開放式建設(shè)、周期短、成本低。大多數(shù)創(chuàng)建出來的集市是功能簡陋、品質(zhì)平庸的。jQuery是一個值得玩味的現(xiàn)象，品質(zhì)極高，但是它帶來的插件市場，卻體現(xiàn)了小集市的另一面，大多數(shù)的jQuery插件的質(zhì)量卻十分低下。
可以說小集市模式創(chuàng)建出來的作品，在單點上，是能夠超越教堂模式作品中對應(yīng)的那部分。前者缺乏一個宏偉的結(jié)構(gòu)，但是在微觀上，它是完善的，可以隨意挪移的。后者雖然具備優(yōu)良的結(jié)構(gòu)，但在單點上并非優(yōu)秀，這也容易讓人懷疑是否其他點上也并不優(yōu)秀，而且教堂式作品的一個特點則是，局部是不可移植的，非獨立性的，這在YUI3中表現(xiàn)十分明顯。
上述對比很容易讓人聯(lián)想到，如果一個架構(gòu)的特性具備單點可移植，可拆卸，自身極其輕量，汲取了大教堂和小集市的優(yōu)點。那必將是一個全新的時代，那是一個可以DIY的時代。原有的大教堂模式由于缺失了靈活性，在迭代迅速的開發(fā)中，必將淘汰。而小集市盡管良莠不齊，好在預(yù)留了選擇權(quán)利給用戶，并且他的開放性也預(yù)示著它的可成長性，所以還有未來可期。
沒錯，如今這個時代已經(jīng)到來。庫通常是一個比框架小一個粒度的單元，模塊則是比庫更小一個粒度的單元。一個庫可能由幾個模塊組成，框架則可能是在幾個庫的基礎(chǔ)上構(gòu)建。不再談?wù)搸旌涂蚣艿脑蚴菍旌涂蚣艿募軜?gòu)部分還給開發(fā)者，以便開發(fā)者可以根據(jù)實際業(yè)務(wù)去構(gòu)建合適的解決方案。任何框架或庫都只具備解決某一方面的能力，不具備普適性。當粒度降低到模塊級別的時候，構(gòu)建任何上層業(yè)務(wù)，可以實現(xiàn)按需使用。由于模塊的粒度更小，所以相對庫而言，更加專注，變優(yōu)秀的成本更低。類比孩子在充滿沙礫的海邊奔跑，但很容易裝滿一口袋的貝殼。對于稍具慧眼的開發(fā)者而言，挑選一堆適合的模塊來解決業(yè)務(wù)的問題，比使用教堂式作品或者更高效。
這種方案因為CommonJS模塊規(guī)范的影響，已經(jīng)在既定事實中成型。在Node中，NPM平臺（https://npmjs.org/）上13000+的模塊數(shù)量可以說明這個問題。前端中由于受到歷史原因的影響，進展較慢，國內(nèi)玉伯的SeaJS在推動此事，Arale是在SeaJS基礎(chǔ)上創(chuàng)建了一些模塊，這類模塊可以非常容易遷移到其他符合CommonJS模塊規(guī)范的環(huán)境中。除此之外騰訊的JX也具備SeaJS的特性，可以輕松將別的庫應(yīng)用到JX中，但是還不夠規(guī)范。
如果非得給這種模塊提供方式一個名稱，我覺得該叫做小教堂模式，具備小集市的小，意味著這個教堂可能只提供祈禱服務(wù)，如果注冊結(jié)婚，則需要換另一家小教堂。但是這類小教堂的服務(wù)是最優(yōu)質(zhì)的。創(chuàng)建這類小教堂只比創(chuàng)建一個優(yōu)異的小集市略費成本，換言之，優(yōu)異的小集市就是小教堂，它的創(chuàng)建方式是沿襲小集市的開放、透明的、有既定目標的成長性的。
另一個考慮是，在大部分的情況下，我們是不需要大教堂的，現(xiàn)實中為了整體環(huán)境，我們寧愿在大教堂中祈禱，但是程序設(shè)計中，我們不會因為喜歡一棵樹木，而買下整塊山頭，我們幾乎不喜歡任何看起來多余的部分。同時我們也不需要小集市，我們需要的是一個品質(zhì)優(yōu)良的商場。開發(fā)者是采購者，采購模塊的過程既是架構(gòu)的設(shè)計的過程。
前文我也提到這種小教堂的模式依然存在不理想的功能重疊、功能多余、功能缺陷、功能沖撞等問題?？芍^說完美的小教堂是可遇不可求的，但一旦它完美，將再難被替換。目前階段的JavaScript模塊開發(fā)還存在著這些問題。是故，如果開發(fā)者了解如何去打造一個優(yōu)秀的JavaScript模塊，并樂于貢獻到開源社區(qū)，這將大幅提升社區(qū)JavaScript水平，后續(xù)的開發(fā)者在做業(yè)務(wù)架構(gòu)時，將具備更優(yōu)質(zhì)的材料來DIY更優(yōu)異的產(chǎn)品。
煉成優(yōu)秀模塊的最佳實踐
其實這并不算是精確的最佳實踐，只是從別的模塊哪里學習到的和自己過去的一些經(jīng)驗，僅做一定的總結(jié)。歡迎補充和討論。
模塊自身的素質(zhì)要求
要寫出一個優(yōu)秀的模塊，模塊自身的素質(zhì)十分重要，如果自身條件太差，成為優(yōu)秀模塊的概率是極小的。這些自身素質(zhì)包括美好的愿景、專注的定位、名字、API設(shè)計、文檔、測試等。
合理的愿景：設(shè)定既定目標
如果你打算寫作一個模塊，并貢獻到開源社區(qū)中，并期望它是優(yōu)異的，并被許多人使用的，那么為它設(shè)定一個既定目標是首要的。如果這個目標是沒有意義，沒有趣味的，那多半沒有人使用，甚至自己開發(fā)到一半都沒有興趣繼續(xù)寫下去。沒有理想的屌絲，注定不能成為高富帥。
對于具備眾多坑爹問題的JavaScript語言而言，找到一個目標并非難事。典型的例子如：jQuery專注解決DOM操作和Ajax、Underscore專注對象和集合的操作、QUnit和Jasmine專注BDD和TDD的單元測試、moment模塊專注解決從Java那里學過來的Date的問題；拿近一些的例子，玉伯的SeaJS專注模塊加載，老趙的Wind.js專注異步編程同步化來解決流程控制問題；拿一個有趣的例子，PNGDrivehttps://github.com/MadeInHaus/PNGDrive這個項目雖然沒有什么實際用處，但是將文件編碼為圖片顯示出來的方式足夠有趣。
另外這個目標必須是既定的。也就意味著餅不用畫為無限的，這個目標一定是可以完成的。如果目標太大，也就意味著模塊自身會變復雜。jQuery兼容各種瀏覽器的DOM操作這個目標，在移動平臺上變得沒有意義，所以存在著Zepto.js這樣的項目。更小的目標意味著模塊自身簡潔，且能夠更專注，目標更容易抵達。一旦抵達目標，該模塊就是穩(wěn)定的，未來被替換的機會極小。
為模塊或項目起一個貼切的名字
模塊需要一個貼切而好記的名字。這個名字何以幫助用戶最直觀地感受模塊。SeaJS在起名上算是一個表率，讓人很容易有海納百川的聯(lián)想，這也正是SeaJS的行為。一個好的名字可以使得模塊的后期推廣事半功倍，而且一旦開始推廣，盡量不要換名字。
不做逾越的事
并非每個使用者都喜歡買一送一的感覺，因為后面這個一，對于使用者而言，并非是期望的，所以它的優(yōu)良無法直觀的判定好壞。無關(guān)的方法一定不要提供。評判一個模塊是否完美，不是可以添加API，而是無法再減少API了。
不污染公共環(huán)境
每個人都不喜歡公共環(huán)境被人污染。破窗效應(yīng)揭示，如果一輛汽車的門窗稍有損壞，不立即修復，那么很快整輛車就會被破壞甚至偷走。 在JavaScript，公共環(huán)境包括全局變量，原型鏈等。jQuery和Underscore為了代碼的寫作方便，占用了$和_兩個符號，盡管他們都提供了noConflict方法來避免沖突，但是抱怨者還是大有人在。所幸這兩個庫太過于知名，幾乎沒有再有的庫來使用這兩個變量名。另一個例子是Prototype.js庫對對象進行擴展時，直接在Array、Object等原生對象的原型鏈上添加方法，盡管它看起來不影響，但是總有沖突的一天，并且使用者并不一定知曉原型鏈被改動，在他的默認上下文中，難保他也不去修改原型鏈。相比Prototype.js的做法，Underscore提供的方法則優(yōu)雅許多，另行提供API來處理操作，而不是修改共有的原型鏈。
在Node和瀏覽器中，global和window是全局對象，如果隨意放置變量到全局對象上，也容易遭到他人修改或者覆蓋你變量的事情。
CommonJS提供的require、exports則十分優(yōu)雅解決這個問題。誰使用，誰引入。而不是通過全局變量。在前端沒有AMD或者CommonJS環(huán)境下，則是采用命名空間和閉包來解決這個問題。
不污染公共環(huán)境是模塊與模塊之間互相不影響的基本保證。如果引入你的模塊，導致其他模塊失效的事情，多半是不招人待見的。
抵制墨菲效應(yīng)
有可能變糟糕的事情，它變糟糕的可能性就會變大。模塊在升級，迭代的過程中，如何避免這種糟糕的事情發(fā)生呢？答案是單元測試。當單元測試覆蓋了你認為會出問題的地方，可以避免相同的錯誤再次發(fā)生。這是模塊穩(wěn)定迭代的基本保證。當我發(fā)現(xiàn)一個僅僅為了解決日期操作的moment模塊，它為數(shù)不多的API竟然具有多達7000+的斷言時，十分驚訝。
過去JavaScript只做簡單的事情，地位低下，所以對于JavaScript的質(zhì)量保證也極少。這個思維需要改變，一個用戶在評估采用你的模塊時，如果單元測試都無法看到，心里該是有多不踏實。
除此之外，還有性能測試，性能測試結(jié)果可以橫向比較，也可以縱向比較，有利于感知模塊的具體性能表現(xiàn)。
數(shù)據(jù)通常容易打動理性的人。
保持簡潔
對于任意看起來復雜的事物，用戶均會覺得它很復雜。老趙的Wind.js（前身是Jscex）是一個想法獨特的模塊，但在提供的API上由于eval，以及需要引入的模塊較多，讓它看起來比較復雜，讓用戶感覺潛意識里復雜，這種復雜的信號很容易變成它有問題的信號，讓人心生疏遠。
將能不暴露給用戶看到的東西，盡量隱藏，過多的步驟只會讓用戶覺得麻煩和不靠譜。
職責單一
這里的反面例子來自于Require.js。如果你用過RequireJS，可以看到require方法是一個變態(tài)的設(shè)置，參數(shù)為’a’、[‘a’]、[‘a.js’]、{}他們的行為都是不一致的。這種參數(shù)類型可以隨意變化是JavaScript的靈活的地方，但是函數(shù)的行為如果也發(fā)生變化，這會讓人產(chǎn)生迷惑。適當?shù)闹剌d并不意味這行為也要完全不同。
功能過多，帶來的問題的可能性也會變大，使用者在調(diào)用過程中也會增加無形的壓力。分離功能可以保持方法職責單一會是你API優(yōu)秀的一部分。
編碼風格
編碼風格一定需要統(tǒng)一，而且編碼風格一定不要顯得外行。如果你的用戶發(fā)現(xiàn)你的編碼風格是PHP或者C#的，他們可能會產(chǎn)生你不是專業(yè)的這個感覺。推薦貼近JavaScript社區(qū)，采用JSLint或JSHint來矯正編碼風格。這有利于源代碼的閱讀，在不同的人之間傳遞不會有不換了一門語言的感覺。
API接口漂亮
API接口漂亮包含幾個方面：
命名
對外API的命名需要謹慎對待，方法名太長、方法名不直觀、方法名大小寫不對、方法名單詞太復雜都會影響到使用者的直觀感受。由于國內(nèi)的英文水平高低不一，使用者遇見不認識的單詞，都會造成障礙。
jQuery在方法命名上十分優(yōu)秀。簡短，直觀，優(yōu)雅。
調(diào)用
實參的傳入也是考驗API設(shè)計者的地方。如果需要調(diào)用者傳入的參數(shù)較多，則該反思該API是否適合暴露給調(diào)用者。如果調(diào)用參數(shù)確實較多，并且支持可選項，則傳入一個對象作為參數(shù)較為合適。由于對象帶有明確的key，獲取參數(shù)也無需一個一個檢測。
$.ajax()是一個典型的例子，它支持的參數(shù)非常多，并且大多可選。所以暴露的API為$.ajax(url, obj)或$.ajax(obj)。
在JavaScript中，鏈式調(diào)用也是讓用戶較為喜愛的一點。Underscore除了提供普通的API外，還支持包裝對象之后進行鏈式調(diào)用。這讓熟悉函數(shù)式編程的人，頓生親切。
習慣
Zepto.js是一個經(jīng)典的案例，它提供了與jQuery幾乎完全兼容的API，為的是照顧用戶對于jQuery的熟悉。這讓它可以零成本被應(yīng)用到移動瀏覽器上。
jQuery的另一件反面例子則是它的each方法，與原生數(shù)組的forEach方法的回調(diào)傳入值次序不同，這與習慣不同的接口，會造成一定反感心理。 在設(shè)計API的過程中，盡量尋找貼合用戶習慣的已有形式，這會讓用戶易于接受。
可擴展性
模塊在開發(fā)的過程中，可以包括有限的部分和無限的部分。有限的部分將會通過項目迭代，臻于完美。如果模塊存在無限的部分，并且在有限的部分留出擴展來衍生無限，這對于模塊的成長，這是一個大大的加分項。
jQuery留出$.fn來供用戶擴展它，形成的影響是大量的jQuery插件涌現(xiàn)了出來。盡管大多數(shù)情況沒有被正確使用，但不能掩蓋它是一個漂亮的設(shè)計。
moment模塊在它的lang部分，也提供了優(yōu)雅的擴展它的部分。使得不同地區(qū)的用戶可以自定義語言的顯示。
擴展性的存在，使得開源社區(qū)能夠參與，能夠起到拋磚引玉的效果，反過來會增進模塊的功能。
使用合適的設(shè)計模式
合適的設(shè)計模式可以讓模塊自身無瑕。不合適的設(shè)計模式則會適得其反。
這里的正反例子都與jQuery相關(guān)。正例子是Deferred的應(yīng)用。過去ajax操作success和fail回調(diào)都必須寫到$.ajax(obj)的參數(shù)對象中，但是Deferred對象使得調(diào)用更加自然：
- $.get("test.php").done(function() {
- alert("$.get succeeded");
- });
LABjs的設(shè)計模式也十分優(yōu)秀，script和wait兩個用于加載和阻塞的API，通過鏈式調(diào)用，其樂融融：
- <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社區(qū)得意的UI組件。
- $(foo).dialog('open')
這類通過傳入?yún)?shù)，又不能得到期望的返回值的場景，并不適合操作這個組件對象，API的參數(shù)傳遞更是顯得不倫不類。如果是直接操作組件對象，則更友好一些。相比jQuery UI，YUI3的組件則優(yōu)秀太多，API漂亮，組件的層次結(jié)構(gòu)分明，易于擴展和自定義，jQuery UI通過插件方法的調(diào)用方式，自定義組件的代價極大。
#p#
合理的目錄結(jié)構(gòu)
開發(fā)方式多半會影響到后續(xù)的使用方式。盡管前端腳本多半都是提供一個文件給用戶，但是在開發(fā)過程中，合理地組織自己項目的目錄結(jié)構(gòu)是值得注意的。jQuery的源代碼目錄中，各個功能點都分別寫在各自的文件中，使得開發(fā)過程中編寫代碼方便。
另一方面，CommonJS的包規(guī)范還定義了以下目錄和文件：
- <span style="color: #888888;">bin doc test lib package.json</span>
分別用于存放二進制文件、項目文檔、單元測試用例、源代碼。package.json文件則用于描述該包的一些包括包名、版本號、依賴等的信息，詳情見http://wiki.commonjs.org/wiki/Packages/1.0。遵循規(guī)范的目錄結(jié)構(gòu)通常更好一點，因為大家都有同一個準則來參考，彼此更熟悉。
巨細的注解
通常用戶真正需要去閱讀你的代碼的時候，是出現(xiàn)問題的時候。在開源社區(qū)，如何讓發(fā)現(xiàn)你問題的人剛你改進代碼，注釋的作用功不可沒。
另外，當一個用戶真正是來欣賞你的代碼時，如果看到Underscore這樣密度的注解時（http://documentcloud.github.com/underscore/docs/underscore.html），還有拒絕它的勇氣嗎？
清晰明了API的文檔
優(yōu)秀的模塊不僅僅體現(xiàn)在代碼寫得好上，更多的體現(xiàn)在如何讓用戶使用時更舒適。API文檔必不可少。我心目中的API文檔應(yīng)該詳細描述方法作用、參數(shù)、返回值的。甚至還應(yīng)該有demo代碼伴隨。
API文檔可以通過jsdoc之類的注解文檔來生成。也可以另起文檔來寫。
API文檔的一個特點是應(yīng)該能方便查找，能在一個頁面中展現(xiàn)完成的，盡量不要頁面跳轉(zhuǎn)或翻頁。
API文檔最大的作用讓用戶精確理解API，使得不造成誤解，和清楚輸入輸出。
Underscore的API文檔（http://documentcloud.github.com/underscore/）借用模版生成了漂亮的頁面，使得查閱方便。
一見鐘情的demo
相比Node，前端JavaScript模塊更擅長做這件事情，尤其是UI庫。男女之間首次見面的第一印象，很大程度可以決定某兩個人是否會談戀愛的概率。demo提供的形式可以影響到用戶的直觀體驗，一般而言，用戶覺得越炫，但是旁邊提示的示例代碼越簡單，越會引發(fā)用戶的好奇心。如果只有代碼，或者只有demo，都會在表現(xiàn)性上打折扣。
對于Node的模塊而言，由于沒有l(wèi)ive demo的感覺，盡量展示sample代碼，讓用戶了解到他的目標是否與模塊的目標一致。不要讓用戶錯過你的模塊，也不要讓你的模塊錯過了它的用戶。
README.md
README文件承擔的作用僅次于demo，無需讓用戶產(chǎn)生心動的感覺，但是一定要引導用戶更深度的了解你的模塊，詳細閱讀你README的人，多半是有興趣使用你的模塊的人在做實地考察了。一個geting start入門是必不可少的，到API文檔的鏈接也應(yīng)該有。如果空落落的README，會立馬有生疏感的。后期用戶的心得體會等相關(guān)文章，也記得更新到README中。
模塊的社區(qū)打造
話說酒香也怕巷子深。在滿足成為優(yōu)秀模塊的基本素質(zhì)要求后的首要事情是如何將模塊推向開源社區(qū)，積極到社區(qū)中宣傳。
放到Github開源：不僅僅是代碼
每一個程序員都應(yīng)該有屬于自己的Github帳號。如果你沒有，不是Github的遺憾，而是你的遺憾。關(guān)于Github有什么，可以參看這篇文章：如何高效利用GitHub （http://www.yangzhiping.com/tech/github.html）。 排除掉文化上帶來的好處。Github可以幫我們托管代碼，幫我們解決版本控制的問題。它可以提供一個wiki，幫我們存放文檔。它提供Issues頁面，使得別人可以為模塊提出意見和反饋。提供Pull Requests頁面，使得別人可以幫我們修改代碼后，供我們合并修改。
交流平臺的創(chuàng)建
交流平臺主要用于討論、答疑，使得模塊作者和用戶之間可以產(chǎn)生思維的碰撞。交流過程可以不斷完善模塊自身的不足，形成文檔。主要的形式有如下：
郵件列表
國外的社區(qū)大多采用Google Groups的郵件列表來交流。郵件列表可以將討論發(fā)送到每一個關(guān)注它的人手中。
實時交流
國外多采用IRC頻道來進行此事。國內(nèi)的情況，可以選擇合適的QQ群來進行交流。
留言版
留言版的功能Github的issue具備了該功能。但是如果具備單獨的介紹頁面或者站點，集成Disqus來收集用戶的反饋會是個不錯的選擇，因為這更符合普通用戶的習慣。
版本控制
這里的版本控制不是git的版本控制。而是模塊的整體版本。標注好模塊的版本是分場重要的，如果用戶需要升級模塊，它能夠得到明確的指導。前端模塊中通常是在文件名上，或者文件內(nèi)部寫明版本。對于Node而言，寫在package.json文件中。
最好能夠在大版本的發(fā)布時，通過正式的新聞頁面，或是郵件列表發(fā)出新聞通知，以顯得版本發(fā)布的正式。
悠揚的歷史：Change Log
不要小看Change log的作用，長長的，細碎的Change log可以給用戶該模塊歷史悠揚的感覺，也能讓用戶體會到寫作該模塊的過程細節(jié)。每次迭代發(fā)布的過程中，展現(xiàn)給用戶看當前的change log也能讓用戶知道改動的影響范圍。如果碰巧發(fā)布了一個用戶需要的方法，他會有收到禮物的感覺。
選擇合適的License
國內(nèi)的環(huán)境中，也許大家不太關(guān)心License的問題。事實上，License的選擇，會影響到用戶的評估。目前只有BSD和MIT兩種License可以讓人放心使用。對于商業(yè)公司而言，如果不是這兩種License，他們需要投入更多的精力和時間周期來評估這個模塊是否可用。
但是對于JavaScript社區(qū)而言，通常采用的是MIT，所以也基本沒有問題。選好License，并在明顯且不重要的位置表明該模塊在什么License下發(fā)行。
發(fā)布到NPM中
在Node中，搞定代碼后，發(fā)布到NPM中是最應(yīng)該做的事。
易于獲得的感覺
npm install module或是一個顯眼又不失素雅的Download按鈕會在潛意識中讓用戶覺得易于獲得，容易集成到現(xiàn)有系統(tǒng)中。不要做了各種分享介紹之后，讓用戶找不到獲取模塊的地方。
持續(xù)集成
一個隨時都能拿出鑰匙，開出跑車的青年，必將被認為是高富帥。支支吾吾不能隨時給出結(jié)果的人，基本是屌絲無疑。
推薦注冊你的項目到travis-ci，并運行它。綠色的Passing時刻昭示該項目的可靠指數(shù)、穩(wěn)定指數(shù)較高。這個小圖標也能幫助你檢測迭代是否出現(xiàn)問題。
漂亮的站點
注冊一個模塊名字的org域名，一套簡潔明了的UI，清晰的導航，簡單的demo等等。細節(jié)在前后的實踐中都有提及。
標致的Logo
如果你沒有任何視覺設(shè)計的天賦，厚著臉皮找你的視覺設(shè)計師同事要一枚吧，盡管它是一個錦上添花的事情，但是Logo在品牌認知上的功勞是不用質(zhì)疑的。
線下分享交流
開發(fā)完模塊后，一定記得分享給團隊的同事，他們應(yīng)該是模塊的首批用戶，他們給予的反饋也是最寶貴的。
另外，還可以在線下社區(qū)分享，將你的模塊的推廣范圍從身邊延續(xù)到這個城市。盡管在線下社區(qū)分享模塊的機會不多，但是一旦有，不要忘記介紹自己得意的模塊給他人。
分享帶來的收益是明顯的，有利于自己梳理對模塊的認識，也能收到用戶的直觀反饋。
及時響應(yīng)反饋
也許你的模塊已經(jīng)很久沒有更新，但是用戶還是會發(fā)來反饋或提出問題，甚至提交pull request，請及時響應(yīng)需求。如果是提出問題，說明你的文檔還不夠完善。如果是提出需求，則說明你最初設(shè)定的目標還沒有完成。
善意營銷：賞金獵人
如果有用戶指出你的低級bug，或是幫你寫作了模塊的體驗文章，這些事情都是值得模塊作者有所表示的時候，因為這些用戶是你的忠實用戶，他們在幫你的模塊成長。有所表示并不意味著要給多少錢，一些有意義的獎品或紀念品更適合拉近這些用戶與你之間的距離。
與兄弟社區(qū)的互動
一個社區(qū)如果過小，需要到隔壁的社區(qū)中發(fā)布一些信息讓大家知曉。如果可以，無論國內(nèi)還是國外的的兄弟社區(qū)的協(xié)助推廣，將會對社區(qū)運作有很大的幫助。友情鏈接是一個典型的方式。
模塊開發(fā)者的自我修煉
模塊自身的優(yōu)秀加上社區(qū)的打造可以保證模塊擁有不錯質(zhì)量和口碑。但是決定模塊能否走得遠，模塊開發(fā)者的自身素質(zhì)也十分重要，這其實模塊的另一個軟素質(zhì)。經(jīng)歷了開發(fā)階段和社區(qū)運作階段后，越發(fā)展到后期，開發(fā)者的自身修煉的影響越會凸顯。
忍得住寂寞&持續(xù)堅持
典型的例子是老趙對于Wind.js的堅持。在對Wind.js的開發(fā)和推廣上，可謂是寂寞的。略呈偏門的異步同步化、eval、編譯等工序，被誤解和排斥的多次。這是需要忍受的，如果沒有持續(xù)堅持和忍住寂寞，模塊就沒有明天。作者的熱情一旦消散，用戶的熱情也必然消散。
簡單專注
前文的愿景部分提及到了簡單專注。簡單專注，不僅僅是在項目初期保持，在長久發(fā)展中，也應(yīng)當如此，只有簡單專注方能保證小教堂的服務(wù)質(zhì)量是最頂尖的。
奉獻精神
模塊開發(fā)和推廣事實上是沒有直接的經(jīng)濟收入的，而且還會耗費大量的時間和精力。但是開源事業(yè)的收益，實際上是無法用金錢進行衡量的。并且這個過程也是自愿自發(fā)的，沒有人會主動來推動你。
如果確實對經(jīng)濟造成影響，可以在頁面上加上donate的鏈接。優(yōu)秀的模塊不會讓這個donate鏈接的功能白費的。
幸運的是開源社區(qū)中不會缺乏具有奉獻精神的人，是他們在推動社區(qū)和技術(shù)發(fā)展。
演講能力
前文提到線下分享，這對于開發(fā)者的演講能力有更多的要求。演講能力的高低，是在另一個層面上提升模塊的表現(xiàn)力，盡管這種能力不需要運行在CPU中。
文筆
模塊開發(fā)者的文筆在文檔的影響上是能夠直觀反映的。除此之外在社區(qū)推廣中，文案的品質(zhì)也有一定的影響。如果開發(fā)者文筆能夠好到用優(yōu)美的文章去傳遞模塊的思想，這是令人愉悅和容易接受的。
人格魅力
模塊的開發(fā)者應(yīng)當具備良好的人格魅力，這包括人際關(guān)系、交流能力等。一個具備人格魅力和一個并不為人所知需要進一步了解的開發(fā)者，他們展現(xiàn)在大家面前的收效是并不相同的。后者更容易吸引他人，為模塊帶來更多的用戶，這些人是你的用戶，也是你的合作者。他們的涌入，會幫助改進模塊。 關(guān)于人格魅力這個軟素質(zhì)，這里不再多說，相信都了解他的重要性的。
總結(jié)
通過對最佳實踐的羅列，我自己相當于重溫了一遍JavaScript開源的一系列文化。而這些最佳實踐部分其實都是必要條件，通過這些最佳實踐，未必保證會有優(yōu)秀的JavaScript模塊產(chǎn)出。但是觀察如今的那些優(yōu)秀模塊，他們基本上都具備這些特征。最后，JavaScript社區(qū)雖然活躍，佼佼者不在少數(shù)，但是整體水平的提升，還需時日，希望此文能夠幫助到一些開發(fā)者并歡迎討論。
關(guān)于作者
田永強，新浪微博@樸靈，前端工程師，曾就職于SAP，現(xiàn)就職于淘寶，花名樸靈，致力于NodeJS和Mobile Web App方面的研發(fā)工作。雙修前后端JavaScript，寄望將NodeJS引薦給更多的工程師。興趣：讀萬卷書，行萬里路。個人Github地址：http://github.com/JacksonTian。
原文鏈接：http://blog.jobbole.com/26101/
【編輯推薦】
