Node.js 最佳實踐 —— 如何在 2018 年成爲更好的 Node.js 開發者

• 原文地址：Node.js Best Practices - How to become a better Node.js developer in 2018
• 原文做者：GERGELY NEMETH
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：Yong Li
• 校對者：guoyang moods445

Node.js 最佳實踐 —— 如何在 2018 年成爲更好的 Node.js 開發者

在過去兩年中，每一年寫一篇關於來年如何成爲更好的 Node.js 開發者的建議已經成了我本身的傳統。今年也不例外！🤗

若是你對我以前的新年建議感興趣，你能夠在 RisingStack 博客上閱讀：

• 如何在 2016 年成爲更好的 Node.js 開發者
• 如何在 2017 年成爲更好的開發者

話很少說，一塊兒來看 2018 年的建議！

採用 async-await

隨着 Node.js 8 的發佈，async 函數已經廣泛可用了。有了 async 函數的存在，你能夠替換掉回調，寫出讀起來和同步代碼同樣的異步代碼。

但什麼是 async 函數？讓咱們回顧一下 Node.js Async 函數最佳實踐 一文：

async 函數可讓你寫出讀起來像是同步代碼的，但實際基於 Promise 的代碼。一旦你使用了 async 關鍵字來定義函數，你就能夠在函數體內使用 await 關鍵字。async 函數被調用時，它會返回一個 Promise。當 async 函數體中返回一個值時，該 Promise 完成（fulfilled）。當 async 函數拋出錯誤時，該 Promise 失敗（rejected）。

await 關鍵字能夠用來等待一個 Promise 完成而且返回結果值。若是傳給 await 關鍵字的值不是一個 Promise，它會將其轉換成一個已完成的 Promise。

若是你想掌握 async 函數，我推薦你瀏覽這些資源：

• Learning to throw again
• Catching without awating
• Node.js async function best practices

讓你的應用優雅地停止

當你部署應用的新版本時，必須更換舊版本。你使用的，不論是 Heroku, Kubernetes, supervisor 仍是任何其它的進程管理器，會首先給應用發送一個 SIGTERM 信號，來通知它即將被停止。一旦應用獲得了該信號，它應該中止接受新的請求，完成全部正在處理中的請求，而且清理它使用的資源。資源一般包含了數據庫鏈接和文件鎖。

爲了讓這一過程更簡單，咱們在 GoDaddy 上發佈了名爲 terminus 的開源模塊，來幫助你的應用實現優雅停止。如今就來看看 ☺️

在公司內採用相同的風格指南

在一個有上百人開發團隊的公司中採用風格指南是頗有挑戰性的 —— 讓每一個人都承認同一套規則簡直難如登天。

恕我直言：你永遠沒法讓上百個開發者承認同一組準則，即便這能帶來顯而易見的收益，譬如讓團隊更快地在項目間切換，而無需費時費力來習慣一套新的（即便只有一點兒不一樣）代碼編寫風格。

若是你正是工做在這種團隊氛圍中，我發現最好的辦法是信任某位經驗豐富的程序員，和其餘人共同努力來決定風格指南包含哪些準則，但他要有最終決定權。在全部人都能遵循同一套準則以前，該準則的具體內容並不重要（我不想引起關於分號的爭吵）。重要的是必須在某一刻有所決定。

把安全當作必備條件

咱們看到愈來愈多的公司被列在 haveibeenpwned 上 —— 我打賭你不想成爲下一個。當你向你的用戶發佈一段新代碼的時候，代碼審覈應該包含安全領域的專家。若是你公司內沒有這樣的人才，或者他們很是很是忙，一個很好的解決辦法是和相似 Lift Security 這樣的公司合做。

而你做爲一名開發者，一樣應該努力更新你的安全知識。爲此，我推薦你閱讀這些材料：

• Node.js 安全檢查清單
• 「開放網絡應用安全項目」網站
• Snyk 博客

在見面會或會議上演講

另外一個成爲更好的開發者，甚至更好地學會表達本身的方法，就是在見面會或者會議上演講。若是你從未試過，我推薦先從一個本地的見面會開始，再去嘗試申請全國的或者國際的會議。

我明白當衆演講會很難。當我準備個人第一次演說時，Speaking.io 幫了我很多忙，我也推薦你去看看。若是你正在準備你的第一次演說，而且想要一些反饋的話，你能夠在 Twitter 上找我談談，我很樂意幫忙！

一旦你有了一個想要在會議上分享的主題，你能夠在 Github 上查看到 2018 Web 會議 徵文集合，這太棒了！

直接使用新的瀏覽器 API 編寫模塊

九月時 Mikeal 在 Modern Modules 上發佈了一篇很好的文章。其中我最喜歡的一件事，就是使用瀏覽器 API 來編寫模塊，當必要時填補（polyfill）Node.js。由此而來的顯著優點就是你能夠將更小的 JavaScript 代碼發佈進瀏覽器中（而且讓頁面加載得更快）。另外一方面，沒人會在乎你的後端依賴是否是太過繁重。

採納應用開發的 12-Factors 法則

應用開發的 12-Factors 原則，描述了網絡應用應當如何編寫的最佳實踐，所以它也出如今今年個人建議列表中了。

隨着 Kubernetes 和其它編排引擎的使用率不斷提高，遵循 12-Factors 法則變得愈來愈重要。它們涵蓋了如下領域：

1. 一份基準代碼，多份部署
2. 顯示聲明和分離依賴關係
3. 在環境中存儲配置
4. 把後端服務當作附加資源
5. 嚴格分離構建和運行
6. 以一個或多個無狀態進程運行應用
7. 經過端口綁定提供服務
8. 經過進程模型進行擴展
9. 快速啓動和優雅停止可最大化健壯性
10. 儘量地保持開發、預發佈、線上環境相同
11. 把日誌當作事件流
12. 後臺管理任務當作一次性進程運行

學習新的 ECMASCript 特性

一些新的 ECMAScript 特性能夠顯著提高你的效率。它們能夠幫你寫出不言自明的清晰代碼。其中我最愛的特性有（老實說它們不是很是新了）：

• 擴展語法
• 剩餘參數
• 解構
• Async 函數

若是你想知道新的 ECMAScript 特性的完整內容，我推薦閱讀這本書 ES6 & Beyond。

---

你想在這份列表中加入別的建議嗎？請在留言中告訴我。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。