這是《為什么我從Python轉(zhuǎn)換到Node.js》這篇文章的后續(xù)?！稙槭裁次覐腜ython轉(zhuǎn)換到Node.js》寫于一年多前，主要是說因?yàn)槲覍ython感到失望于是打算嘗試Node。

一年的內(nèi)部CLI工具，客戶項(xiàng)目和更新公司產(chǎn)品的歷練，正是我所學(xué)到的東西。不僅是Node，JavaScript也很不錯(cuò)。

[[166701]]

易于學(xué)習(xí)，但不可能完全掌握

Node很容易學(xué)習(xí)。特別是如果你已經(jīng)懂得一些JavaScript知識的話。用Google搜索一些初學(xué)者教程，擺弄一下Express，然后你 就可以開始你的征程了。然后你會意識到你需要選擇一個(gè)數(shù)據(jù)庫。沒問題，我們可以搜索NPM。哦，那里已經(jīng)有不少優(yōu)雅的SQL軟件包了。之后你會發(fā)現(xiàn)所有的 ORM工具爛極了，而基本的驅(qū)動(dòng)程序是你***的選擇?，F(xiàn)在，你被困在了實(shí)施冗余模型和驗(yàn)證邏輯中。在那不久，你開始編寫更復(fù)雜的查詢，并開始迷失在 callbacks中。你終于沖出了callbacks地獄，并開始使用promises庫?，F(xiàn)在，你差不多可以“promise化”所有事情，并且美滋 滋地小酌一杯。

所有這些是想說明，Node生態(tài)系統(tǒng)感覺像總是在不斷前進(jìn)中。卻不是用一種很好的途徑。“勝過”舊工具的新工具似乎每天都在問世?？倳幸粋€(gè)新的閃 亮的東西來替代另一個(gè)。你會驚訝于這種情況的發(fā)生有多么容易，你和社區(qū)看上去都在鼓勵(lì)它。你使用Grunt?。棵總€(gè)人都使用Gulp??？不要等待，現(xiàn)在就 使用本地NPM腳本！

包括瑣碎代碼——即不超過10行代碼——的軟件包每天都數(shù)以千計(jì)地從NPM下載。說真的??？你需要用于數(shù)組類型檢查的依賴關(guān)系？并且這些軟件包被一些大型工具，例如React和Babel所用。

你永遠(yuǎn)不可能用一種極快的速度掌握一些東西，更不要說潛在的依賴關(guān)系的不穩(wěn)定了。

處理錯(cuò)誤時(shí)，祝你好運(yùn)

以前使用其他語言如Python，Ruby或PHP的你，還在期望拋出和捕獲錯(cuò)誤，或甚至是從函數(shù)返回錯(cuò)誤作為錯(cuò)誤處理的簡單的方法嗎？Node可 不這樣。相反，你需要四處傳遞錯(cuò)誤在你的callbacks（或promises）中——對，不拋出異常。直到你了解的不僅僅是callbacks，并且 試圖遵循堆棧跟蹤，這才不起效用。更不必說，如果你忘了在錯(cuò)誤上返回callbacks，那么它就會繼續(xù)運(yùn)行并觸發(fā)另一錯(cuò)誤設(shè)置，在你返回最初的錯(cuò)誤設(shè)置 之后。你需要讓你的客戶多加一倍的錢以彌補(bǔ)用來調(diào)試的時(shí)間。

即使你設(shè)法想出了針對自己錯(cuò)誤的堅(jiān)實(shí)標(biāo)準(zhǔn)，你也不能確認(rèn)（而不讀取源）你安裝的許多NPM軟件包遵循相同的模式。

這些問題導(dǎo)致了“catchall”異常處理程序的使用，這樣就會記錄問題。請記住，Node是單線程的。如果有什么東西鎖定了該進(jìn)程，那么一切就會轟然倒下。但是使用Forever，Upstar和Monit很酷，不是嗎？

callbacks，promises還是generators??？

為了處理callbacks地獄，錯(cuò)誤處理和通常難以閱讀的邏輯，越來越多的開發(fā)人員已經(jīng)開始使用Promises。這基本上是編寫看上去像同步碼 但沒有瘋狂的callbacks邏輯的一種方式。不幸的是，沒有任何“標(biāo)準(zhǔn)”（一切都像在Javascript中其他人）用來實(shí)施或使用 Promises。

現(xiàn)在最明顯的庫是Bluebird。它相當(dāng)不錯(cuò)，速度快，又能剛好完成工作任務(wù)。不過，我發(fā)現(xiàn)不得不封裝需求到Promise.promisifyAll（）特別有黑客范。

在大多數(shù)情況下，我會使用優(yōu)秀的async庫，以避免callbacks。這感覺更自然。

***，我對于Node的經(jīng)驗(yàn)是，Generators變得越來越流行。我并沒有深入了解Generators，因此無法給出太多的反饋。非常期待聽到大家關(guān)于Generators的經(jīng)驗(yàn)。

糟糕的標(biāo)準(zhǔn)

***一件令我沮喪的事情是缺乏標(biāo)準(zhǔn)。每個(gè)人對上述個(gè)要點(diǎn)該如何處理似乎都有自己的看法。Callbacks？Promises？錯(cuò)誤處理？構(gòu)建腳本？無窮無盡。

那也只是抓住了表明的東西而已。似乎彼此之間也不同意如何編寫標(biāo)準(zhǔn)的JavaScript代碼。不妨快速Google檢索“JavaScript編碼標(biāo)準(zhǔn)”，你就會明白我的意思。

我意識到很多語言都沒有嚴(yán)格的結(jié)構(gòu)，但它們通常卻都具有由語言的實(shí)際維護(hù)人員創(chuàng)建的標(biāo)準(zhǔn)指南。

我認(rèn)為只有一個(gè)確實(shí)有助于JavaScript，它是由Mozilla編寫的。

關(guān)于Node的***一些想法

我花了一年時(shí)間試圖使用Javascript以及更特別的Node為我們的團(tuán)隊(duì)工作。但是不幸的是，在此期間，我們的時(shí)間更多的是花在了攻讀文檔，提出標(biāo)準(zhǔn)，討論庫還有調(diào)試瑣碎的代碼上。

那么我會推薦它用于大規(guī)模的產(chǎn)品嗎？絕對不會。其他人有沒有試著這樣做呢？當(dāng)然有過。我也嘗試過。

但是，我建議JavaScript用于前端開發(fā)，例如Angular和React（或者你也可以有其他選擇）。

此外，我認(rèn)為Node適合簡單的后端服務(wù)器，并且服務(wù)器主要用于webSockets或API  ray。這使用Express很容易快速完成，并且我們正是用在了我們的Quoterobot PDF處理服務(wù)器上。這是一個(gè)單獨(dú)的文件，包含186行代碼，其中還包括了空格和注釋。Node用得真心順手。

回歸Python

你可能會想，現(xiàn)在的我在干什么呢？好吧，我依然在使用Python編寫web產(chǎn)品和API的主要部分。主要在Flask或Django中，使用Postgres或MongoDB。

它經(jīng)受住了時(shí)間的考驗(yàn)，有一些偉大的標(biāo)準(zhǔn)和庫，它易于調(diào)試并且表現(xiàn)良好。當(dāng)然它也有它的缺點(diǎn)。但世上沒有***的東西。出于某種原因，Node抓住了我的眼球，讓我深陷其中。我不后悔曾擁抱過它，但我確實(shí)覺得我本不應(yīng)該花費(fèi)這么多的時(shí)間在它上面。

我希望JavaScript和Node將來能夠得到改善。我很樂意重新審視它。

請告訴我你的經(jīng)驗(yàn)？你有沒有遇到我這樣類似的問題？你是否最終還是決定轉(zhuǎn)換回到更舒適的那種語言？

譯文鏈接：http://www.codeceo.com/article/my-nodejs-1-year.html
英文原文：AFTER A YEAR OF USING NODEJS IN PRODUCTION