先不說房價，堵車，霧霾。。。先說說我這半年使用 Node.js 的經(jīng)驗吧。。。都是工作上遇到的問題，血的教訓(xùn)。。

1.精確版本號

“一定要精確到具體版本號！使用*直接滾，^和~都不行！”，早上剛到公司，我們服務(wù)器的頭頭滿眼血絲（估計又凌晨幾點(diǎn)睡的），對我抱怨道：“媽蛋，以前寫的代碼package.json里的版本和服務(wù)器正在運(yùn)行的版本不一樣。安裝最新的又咣咣一頓報錯?！贝颂幨÷詭浊ё帧?。。

好吧。我先打自己臉。以前只會用*。。。大多時候也沒必要寫死版本號，使用^和~也可以。掃一下盲：

semver
node.js 中的版本管理

2.測試

一定要寫測試用例。就拿我來說，我負(fù)責(zé)的那塊包含過濾部分（用正則神馬的過濾文本，提取出有用的文本）。有了測試用例，每次改動過濾規(guī)則后，npm test 下，妥妥的。依個人喜好挑選使用的測試模塊，mocha, should, tape, tap, supertest 等等。

嘗試本地運(yùn)行，測試成功后才上傳到服務(wù)器。我好幾次改完代碼（就簡單的改了幾行）以為怎么可能會出問題，結(jié)果一重啟服務(wù)器就掛了。。尼瑪少了括號什么的。。這種問題也可以通過使用jslint或jshint等編輯器插件來檢測低級語法錯誤。

服務(wù)器代碼備份。目前我使用的方法：起初服務(wù)器上有兩個一模一樣的工程（git庫，文件名不一樣），一個正在運(yùn)行，另一個當(dāng)作備份。當(dāng)有代碼改動時，到備份工程下 git pull ，然后停止正在運(yùn)行的程序，啟動備份的程序。假如程序經(jīng)過一段時間沒有掛掉也就是感覺比較穩(wěn)定后，將此工程當(dāng)作主，另一個工程當(dāng)作備。當(dāng)又有改動時，重復(fù)以上步驟，主備來回切換。假如程序掛掉了，則切換回較穩(wěn)定的備即可。

3.使用 debug

寫程序免不了調(diào)試，很多人喜歡并習(xí)慣用萬能的 console.log() ，包括我。。就個人而言，我使用 console.log() 調(diào)完后，不是刪掉就是注釋掉。刪掉吧以后也許還會用到，注釋掉吧怪難看。這個時候不妨用用 debug 模塊。暫時沒用過 node-inspector，不做評價。

4.保持代碼精簡

嘗試用較少的代碼完成較多的事情，也是對自己能力的提升與考驗。包括正確的縮進(jìn)，恰當(dāng)?shù)淖兞棵?，清晰的代碼組織結(jié)構(gòu)等等。。代碼精簡了，漂亮了，當(dāng)出問題了回頭查錯也快，總比先弄明白一團(tuán)亂糟的代碼干了些什么就花了幾個小時強(qiáng)。

假如團(tuán)隊沒有使用CoffeeScript的話就不要使用它。一是別人無法讀懂你的代碼幫你糾錯。二是出錯后顯示出錯的行數(shù)和coffee代碼的行數(shù)不一樣。。。自己的開源項目可以用用。

5.多請教，保持獨(dú)立思考

剛開始工作的時候，我也各種一頭霧水，包括技術(shù)上的不足和業(yè)務(wù)邏輯上的欠缺，常常請教團(tuán)隊內(nèi)的大牛。而后我會嘗試彌補(bǔ)技術(shù)上的不足，理清業(yè)務(wù)上的邏輯。后來有一次，我要根據(jù) PM 的要求設(shè)計一個 api，既要考慮用戶的需求（多客戶端的情況），客戶端的需求和行為，數(shù)據(jù)庫的設(shè)計（怎么存冗余少，查詢次數(shù)少，易擴(kuò)展，易修改，差量查詢）等等，考慮了一個周多，幾近崩潰。。。雖然我和頭頭商量了好多次，但它總是給我理邏輯，不告訴我方法。后來終于找了一種還算不錯的解決方式。。他后來也告訴我，想讓我保持獨(dú)立思考去解決問題，這樣才能有提高。。

6.使用現(xiàn)有的庫

目前npm上已經(jīng)有近9W的第三方模塊了，理論上想用的都能在npm上找到，當(dāng)然npm上不乏非常多的優(yōu)秀的模塊，文檔全面，使用也非常方便，通常都會滿足需求。假如你發(fā)現(xiàn)某個模塊能滿足大部分需求可以有功能上的完善，或有bug，可以去github上提pr，假如你發(fā)現(xiàn)沒能找到滿足的模塊的話，可以自己創(chuàng)建個并npm publish到npm上與大家共享。當(dāng)然你發(fā)現(xiàn)某類實現(xiàn)某個功能的模塊都很shit的話，你也可以publish個不shit的。

7.保持簡單

假如你想展示一個餅圖的話，用 HTML5 canvas 或 CSS3 即可，沒必要用 C++ 的 canvas 庫畫一個圖片，“光下載依賴的庫就 400+ MB”，頭頭如是說。

8.良好的文檔

良好的文檔是客戶端與服務(wù)器團(tuán)隊交流的最重要的渠道。文檔寫得明明白白了，假如客戶端請求出錯了，就可以先去查看文檔（比如每個錯誤代碼代表了什么），而不是每次出問題了就來找服務(wù)器的人討論。PS: 一些 http 請求示例盡量用 curl 寫，而不是 js 中的對象等的方式，也許你看的很懂，但客戶端的人不懂 js。

9.配置文件

在每個工程目錄下都建一個配置文件，如 config.js/config.json。而不是寫死在代碼里。如：

{
  "app": 3000,
  "mongo": {
    "host": "localhost",
    "port": 27017
  },
  "redis": {
    "host": "localhost",
    "port": 6379
  }
  ...
}
10.使用 pm2

使用 pm2 等這種進(jìn)程管理工具，很方便，最不濟(jì)進(jìn)程掛掉了還能自動重啟吶。沒用過 forever 不做評價。。還有 grunt 神馬的也沒用過，不做評價。

最新評論