我的 NodeJS 一年之旅總結
本文由碼農網 – 小峰原創翻譯,轉載請看清文末的轉載要求,歡迎參與我們的付費投稿計劃!
這是《為什麼我從Python轉換到Node.js》這篇文章的後續。《為什麼我從Python轉換到Node.js》寫於一年多前,主要是說因為我對Python感到失望於是打算嘗試Node。
一年的內部CLI工具,客戶專案和更新公司產品的歷練,正是我所學到的東西。不僅是Node,JavaScript也很不錯。
易於學習,但不可能完全掌握
Node很容易學習。特別是如果你已經懂得一些JavaScript知識的話。用Google搜尋一些初學者教程,擺弄一下Express,然後你就可以開始你的征程了。然後你會意識到你需要選擇一個資料庫。沒問題,我們可以搜尋NPM。哦,那裡已經有不少優雅的SQL軟體包了。之後你會發現所有的ORM工具爛極了,而基本的驅動程式是你最好的選擇。現在,你被困在了實施冗餘模型和驗證邏輯中。在那不久,你開始編寫更復雜的查詢,並開始迷失在callbacks中。你終於衝出了callbacks地獄,並開始使用promises庫。現在,你差不多可以“promise化”所有事情,並且美滋滋地小酌一杯。
所有這些是想說明,Node生態系統感覺像總是在不斷前進中。卻不是用一種很好的途徑。“勝過”舊工具的新工具似乎每天都在問世。總會有一個新的閃亮的東西來替代另一個。你會驚訝於這種情況的發生有多麼容易,你和社群看上去都在鼓勵它。你使用Grunt!?每個人都使用Gulp!?不要等待,現在就使用本地NPM指令碼!
包括瑣碎程式碼——即不超過10行程式碼——的軟體包每天都數以千計地從NPM下載。說真的!?你需要用於陣列型別檢查的依賴關係?並且這些軟體包被一些大型工具,例如React和Babel所用。
你永遠不可能用一種極快的速度掌握一些東西,更不要說潛在的依賴關係的不穩定了。
處理錯誤時,祝你好運
以前使用其他語言如Python,Ruby或PHP的你,還在期望丟擲和捕獲錯誤,或甚至是從函式返回錯誤作為錯誤處理的簡單的方法嗎?Node可不這樣。相反,你需要四處傳遞錯誤在你的callbacks(或promises)中——對,不丟擲異常。直到你瞭解的不僅僅是callbacks,並且試圖遵循堆疊跟蹤,這才不起效用。更不必說,如果你忘了在錯誤上返回callbacks,那麼它就會繼續執行並觸發另一錯誤設定,在你返回最初的錯誤設定之後。你需要讓你的客戶多加一倍的錢以彌補用來除錯的時間。
即使你設法想出了針對自己錯誤的堅實標準,你也不能確認(而不讀取源)你安裝的許多NPM軟體包遵循相同的模式。
這些問題導致了“catchall”異常處理程式的使用,這樣就會記錄問題。請記住,Node是單執行緒的。如果有什麼東西鎖定了該程式,那麼一切就會轟然倒下。但是使用Forever,Upstar和Monit很酷,不是嗎?
callbacks,promises還是generators!?
為了處理callbacks地獄,錯誤處理和通常難以閱讀的邏輯,越來越多的開發人員已經開始使用Promises。這基本上是編寫看上去像同步碼但沒有瘋狂的callbacks邏輯的一種方式。不幸的是,沒有任何“標準”(一切都像在Javascript中其他人)用來實施或使用Promises。
現在最明顯的庫是Bluebird。它相當不錯,速度快,又能剛好完成工作任務。不過,我發現不得不封裝需求到Promise.promisifyAll()特別有黑客範。
在大多數情況下,我會使用優秀的async庫,以避免callbacks。這感覺更自然。
最後,我對於Node的經驗是,Generators變得越來越流行。我並沒有深入瞭解Generators,因此無法給出太多的反饋。非常期待聽到大家關於Generators的經驗。
糟糕的標準
最後一件令我沮喪的事情是缺乏標準。每個人對上述個要點該如何處理似乎都有自己的看法。Callbacks?Promises?錯誤處理?構建指令碼?無窮無盡。
那也只是抓住了表明的東西而已。似乎彼此之間也不同意如何編寫標準的JavaScript程式碼。不妨快速Google檢索“JavaScript編碼標準”,你就會明白我的意思。
我意識到很多語言都沒有嚴格的結構,但它們通常卻都具有由語言的實際維護人員建立的標準指南。
我認為只有一個確實有助於JavaScript,它是由Mozilla編寫的。
關於Node的最後一些想法
我花了一年時間試圖使用Javascript以及更特別的Node為我們的團隊工作。但是不幸的是,在此期間,我們的時間更多的是花在了攻讀文件,提出標準,討論庫還有除錯瑣碎的程式碼上。
那麼我會推薦它用於大規模的產品嗎?絕對不會。其他人有沒有試著這樣做呢?當然有過。我也嘗試過。
但是,我建議JavaScript用於前端開發,例如Angular和React(或者你也可以有其他選擇)。
此外,我認為Node適合簡單的後端伺服器,並且伺服器主要用於webSockets或API ray。這使用Express很容易快速完成,並且我們正是用在了我們的Quoterobot PDF處理伺服器上。這是一個單獨的檔案,包含186行程式碼,其中還包括了空格和註釋。Node用得真心順手。
迴歸Python
你可能會想,現在的我在幹什麼呢?好吧,我依然在使用Python編寫web產品和API的主要部分。主要在Flask或Django中,使用Postgres或MongoDB。
它經受住了時間的考驗,有一些偉大的標準和庫,它易於除錯並且表現良好。當然它也有它的缺點。但世上沒有完美的東西。出於某種原因,Node抓住了我的眼球,讓我深陷其中。我不後悔曾擁抱過它,但我確實覺得我本不應該花費這麼多的時間在它上面。
我希望JavaScript和Node將來能夠得到改善。我很樂意重新審視它。
請告訴我你的經驗?你有沒有遇到我這樣類似的問題?你是否最終還是決定轉換回到更舒適的那種語言?
譯文連結:http://www.codeceo.com/article/my-nodejs-1-year.html
英文原文:AFTER A YEAR OF USING NODEJS IN PRODUCTION
翻譯作者:碼農網 – 小峰
[ 轉載必須在正文中標註並保留原文連結、譯文連結和譯者等資訊。]
相關文章
- 我自由職業頭一年總結
- 【我的產品觀】開發wangEditor一年總結
- 我的 2020 總結,我在螞蟻成長的這一年
- 一年到頭的總結
- 一年工作的總結 (轉)
- nodejs面試總結NodeJS面試
- 工作十一年總結
- 從這5個方面,總結我當PM的第一年
- 2020年終總結-我在美國度過的一年
- it生活的第一年總結
- 我的總結
- 一年產品汪的個人總結
- 我的年終總結
- 我的工作總結
- 我的個人總結
- 一個JAVA開發一年的總結Java
- 阿星的回家之旅 | 2021 年中總結
- Bugtags 創業一年總結創業
- 【我的總結——思想篇】
- 學習前端近一年的反思與總結前端
- 我的大前端之旅前端
- 2022年是最爛的一年嗎?我的2022年終總結
- 創業一年失敗總結:我用100萬買來的6點經驗創業
- 一年前端近期面試總結前端面試
- 【年終總結--我的成長】
- 2021年終總結:平平無奇的一年
- 畢業一年左右的前端妹子面經總結前端
- 一年前端使用 react 系列 總結前端React
- 我的html基礎總結—1HTML
- 2021我的個人總結
- 我的刷題經驗總結
- 2017,我的年終總結
- 我的2013年總結
- 自由職業,我的半年總結
- 總結2018這一年的記憶片段
- [譯] 我與 Flutter 的一年Flutter
- 從部落格時間軸總結這一年
- 一年級上學期總結以及規劃