2019 年，19 種方法讓本身成爲更好的 Node.js 工程師

原文做者：Yoni Goldberg

譯者：UC 國際研發 Jothy

寫在最前：歡迎你來到「UC國際技術」公衆號，咱們將爲你們提供與客戶端、服務端、算法、測試、數據、前端等相關的高質量技術文章，不限於原創與翻譯。

編者按：文中做者爲你們提供了19種方法，大多數方法後面都提供了例子，若是你對這些例子感興趣，請直接查看英文原文，並訪問例子中的連接。

簡介

我已經聚集了 19 項 2019 年可能有價值的技能和主題。請別爲難我 - 我和大多數開發人員同樣，不可能熟悉每個主題。 這些只是我所關注的使人興奮的事情，JavaScript 的視野永無止境。

我叫 Yoni Goldberg，是一名獨立的 Node.js 顧問，也是《Node.js 最佳實踐》的合著者。 我與美國，歐洲和以色列的客戶一塊兒研究他們的 Node.js 應用。 個人服務包括代碼、應用程和架構審查、測試和 CI、高級培訓課程以及其餘服務。 你能夠關注個人推特(https://twitter.com/goldbergyoni)。

1. 使用類型（type）和模式（schema）。 TypeScript 是 2019 年的極佳選擇

事實證實，以無類型方式編碼會拔苗助長，而且容易出錯（參見研究）。 這並不意味着你必須一直使用嚴格類型的語法，而是經過使用 JSON Schema（或 Joi）驗證你的實體/模型來選擇你想要的原理圖代碼程度，用靜態類型來註釋原生 JS（ 請參閱 Facebook Flow）或持續使用強類型語法如 TypeScript。 後者在 2018 年取得了顯著的發展勢頭，彷佛已成爲 Node 領域的共識。 若是你計劃使用 TypeScript，先問問本身，你的用法是否不只僅是類型（Typing）功能，不然使用接口和抽象類會把你帶入一個你從何嘗試過的範例。

參考連接：

• 研究地址：http://ttendency.cs.ucl.ac.uk/projects/type_study/documents/type_study.pdf

• JSON 模式：https://www.npmjs.com/package/jsonschema

• Joi：https://www.npmjs.com/package/joi

• Facebook Flow：https://github.com/facebook/flow

例子：

• 使用 JSON Schema 的顯式模型架構：https://www.npmjs.com/package/jsonschema

• 使用 Facebook Flow 靜態輸入原生 JS：https://github.com/facebook/flow

• 使用 Typed 語法 TypeScript：https://www.typescriptlang.org/

2. 豐富你的 Linters

Linters 是免費的午飯，經過 5 分鐘的設置你能夠免費得到一個自動駕駛員來保護你的代碼並在輸入時監測重大問題的發現。 linting（化妝棉）與 cosmetics（化妝品）相關的日子已經一去不復返了（沒有分號！）。 現在，Linters 能夠捕獲嚴重的問題，例如錯誤未正確拋出，丟失信息，Promise 永不 resolve，以及其它你從未想在代碼中看見的痛點。

例子：

• eslint-plugin-chai-expect 能夠發現沒有斷言的測試

• eslint-plugin-promise 能夠發現未 resolve 的 Promise（你的代碼永遠不會繼續）

• eslint-plugin-security 能夠發現可能用於 DOS 攻擊的正則表達式

3. 多一點 Java，少一點 Ruby - 加深你的架構知識

Node.js 生態系統的架構和設計知識不多，你們都在講微服務，但只談了一些內部結構。而大多數應用和示例都是 MVC 概念和 Ruby 的其餘可疑模式。這有什麼問題？例如，MVC 是爲服務內容構建的，而且是構建健壯後端的一種使人印象深入的技術（Uncle Bob：「MVC 是一種傳遞機制，而不是應用架構」）。你真的能夠描述整個業務邏輯、規則、數據訪問、與 控制器和模型中的其餘微服務的通訊嗎？有關其餘設計問題和可能的補救措施，請參閱下面的示例。

我絕對不建議使用沉重的 Java/Spring 模式（咱們來到 Node 領域是有緣由的，不是嗎？:)），只是挑選一些提供超值而不犧牲應用簡單性的想法。

例子：

• 你是否閱讀過個人《Node.js 最佳實踐》第 1 部分 - 架構？

• 避免使用 Express 對象擾亂你的業務邏輯，閱讀有關域驅動設計的內容（請參閱此新穎書籍的縮短版本）和 Hexagonal 架構

• 將邏輯和數據訪問代碼混合在一個類中（Active Record 模式 - 在使用 Mongoose 和 Sequelize 的開發人員中很是流行）很容易致使更難測試的膨脹對象。 請考慮使用數據映射器模式。

• 瀏覽一下這個實現領域驅動設計和乾淨架構的優秀 Node.js 樣板代碼

4. 規劃如何利用異步 Hook 來得到更好的跟蹤和上下文

單線程模型有一個主要缺點 - 請求丟失上下文：當它們流經多個文件並執行異步操做時，變量在其整個生命週期中不會被保留。爲何這很痛苦呢？例如，開發人員一般但願在每一個日誌中包含惟一標識符，以便稍後能夠關聯同一請求的全部日誌 - 這在 2018 年不是很容易。2019 帶來了新的亮點，異步 hooks 正是其中之一（不是全新的但很快就會退出實驗模式）。簡單地說，這是一種在異步操做開始和結束時隨時注入自定義代碼的機制。鑑於此，能夠關聯同一請求的全部代碼並保留上下文。這爲許多自定義程序包奠基了基礎，這些程序包將 Node 的跟蹤和上下文功能提高到了一個新的水平。

例子：

• cls-hooked 容許在整個請求生命週期中共享變量和上下文

• Jaeger 客戶端將可視化整個系統的請求流，甚至是微服務和服務器（開放跟蹤標準的一部分，須要專用服務器來記錄全部活動）

• 瞭解異步 hook 機會以及如何對其進行編碼。由 @guysegev 提出

5. 瞭解最新的 Serverless 功能：它已經準備好在強大的基礎設施領域展開激戰（Kubernetes 殺手？）

注意：FaaS 和 Serverless 這兩個詞在這裏能夠互換使用，儘管它們並不徹底相同。實際上，我指的是雲供應商 FaaS 服務，如 Lambda 和 Google Functions。

最初，FaaS 用於開發微任務，而不是用於強大的「微服務」應用。隨着他們的受歡迎程度愈來愈高，雲供應商的胃口愈來愈大，很快就出現了新的功能。FaaS 在 2019 年忽然出現，它彷佛是一個強大應用的基礎設施。它如今能夠與 Kubernetes 競爭並提供大型應用程序嗎？有些人認爲 Serverless 和 Faas 是正交技術，但實際上 2019 年的每個新的雲應用都必須三選一（實際上每一個雲供應商 UI 上都會顯示這個選擇）：（1）裸機實例，如 EC2 或 GCP 計算（ 2）Kubernetes 或（3）FaaS。所以，可以比較 K8S 與 FaaS/Serverless 並告知後果成爲強制性設計技能。

附：如下示例僅爲方便起見與 AWS 相關。

例子：

• AWS Lambda SAM 工具容許在本地定義和運行 FaaS

• AWS Lambda 如今支持灰度部署！

• AWS Lambda 層容許在多個 FaaS 之間重用邏輯（模擬典型微服務的域/業務邏輯層）

6. 瞭解即將支持的最新 JavaScript 功能

我不是追逐每一種語言新功能的狂熱粉絲，有時這些閃亮的玩具會違背代碼的簡單性。 一些很是有價值的 Javascript 功能不時會出現（好比兩年前 async/await 的介紹），因此能夠了解 TC39 的提議和 node.green 以找到適合你編碼風格的有吸引力的新功能。

例子：

• Class 層面字段位於第 3 階段（最後階段），並可能在 2019 年支持

• BigInt 處於第 3 階段（最後階段），在與其餘產生巨大數字的微服務，機器或數據倉庫進行交互時可能會有所幫助

• 異步迭代器（Matt Krick）和 †promise - 終於已經支持，若是你沒用過，那麼值得一試

7. 熟悉至少一種 API 技術。 GraphQL 是 2019 年的不錯選擇

REST 風格的 API 很是契合它的構建初衷：能夠很好地控制實體的修改和查詢。你有財務記錄系統嗎？你可能但願設計很是嚴格的端點，即單個顯式數據模型。然而，在其餘很是常見的用例中，REST 風格確實不足，好比執行可能返回不一樣數據集的相似查詢，低帶寬網絡決定最小化 API 負載，強調速度的機器到機器通訊，僅舉幾例。你應該換一個嗎？絕對不是，只是混用一下別的。 API 不是你的架構，它們只是應用程序的一個端口（即入口點），而且多個 API 樣式能夠輕鬆共存，甚至在像 Express 這樣的單一 Web 框架之上。

那麼要學哪個？你最好的選擇多是 GraphQL，它直接就是主流。它的生態系統已經很是成熟，它能夠提供很是流行的用例，如動態搜索和分層數據源。另外一方面，Grpc 仍然是一種適合服務器到服務器通訊用例的小衆技術，你能夠得到最小的開銷（例如，Pub-sub/消息隊列系統）。

例子：

• 對比學習很棒 - REST vs Graph vs grpc

• 瀏覽 GraphQL，Node＆Express 教程

• 觀看簡短的 YouTube（11分鐘） - 什麼是 GraphQL？

8. 超越單元和集成測試 - 使用全新測試技術豐富你的測試產品組合

你熟悉測試金字塔，單元，集成和端到端測試了？很棒，這些是成功測試策略的基礎。然而，在過去 10 年中，開發世界經歷了巨大的變化，但測試模型保持不變，咱們好奇如何測試像微服務、豐富的前端和 Serverless 這樣的東西。一些現代技術與傳統堆棧相輔相成，有時甚至能夠替換它，以實現 ROI 更好的更精簡的測試策略。

例子：

• 消費者驅動合約能夠防止微服務之間或你與 API 消費者之間的問題

• 快照測試不只能夠用於 UI，還能夠用於防止 API 迴歸

• 組件測試是微服務測試的均衡方法

• 請參考個人 YouTube 視頻 「Beyond Unit Tests：5 Shiny Node.JS Test Types（2018）」

視頻：Yoni Goldberg 的 5 項閃亮測試技術

https://www.youtube.com/watch?v=-2zP494wdUY&feature=youtu.be

9. 使你的監控與 SRE/DevOps 最佳實踐保持一致

2019 年，即便是一箇中型應用也可能由數十個物理移動部件構成，而且應該很是謹慎地立於這個「大型管絃樂隊」之上。然而，大多數開發者沒有花功夫學習監控和告警課程，各路大牛十分樂意教授這門課。例如，開發人員一般會優先考慮並專一於 CPU 和內存等內部硬件指標，而不是從直接影響最終用戶的指標開始，例如錯誤率或延遲（「我稱之爲基於症狀的監控」，來自'個人警示哲學'）。那些面向客戶的指標也被稱爲「黃金信號」，而在 2019 年，也許你但願由此開始並採用相似的最佳實踐。

例子：

• 瞭解 4 個監測'黃金信號'

• 閱讀《Google Site 可靠性工程》，或者至少閱讀有關監控的章節

• request-stats 包也許有助於你提取這些面向客戶的指標，以便與監控系統共享

10. 像攻擊者同樣思考：經過學習攻擊工具和技術來提升安全級別

若是你不能像攻擊者那樣思考，你就不能像防守者同樣思考。2019 年，你不應將防護工做外包給第三方公司或僅依靠靜態安全掃描程序：各類攻擊的數量是壓倒性的（開發管道和 NPM 是最新趨勢），應用更改的速度是難以控制的 - 在開展安全研討會兩天後，團隊能夠添加幾個新的 AWS 服務，數據庫類型和新的 IAM 角色......所以，隱藏的開發者成爲最大的威脅，教育他們彷佛是最終的補救措施。你必須將安全 DNA 植入到你和你的團隊中，而且謹慎進行全部操做。

一旦你開始這麼作了，事實會證實並無那麼可怕。只需熟悉常見的攻擊類型和工具，繪製應用架構和流程，並思考如何攻擊它。慢慢地在不知不覺中，你將在每一個設計決策和每一行代碼中開始考慮安全性。

例子：

• 嘗試 OWASP ZAP - 一款豐富的評估和滲透工具，甚至容許新手探索應用的安全級別

• 閱讀個人 Node.js 安全最佳實踐列表，其中包含 23 個以上的攻擊想法，包括 JavaScript 代碼示例

• 進行每個月威脅分析會議，讓你的團隊試着查看應用設計並提出攻擊。聽起來很無聊？不必定，若是你把它遊戲化，獎勵找到漏洞的成員，或者成立兩個相互競爭的組，一組設計模塊，一組找漏洞

11. 制定包更新策略。 2018 年吸收的教訓：過早更新很危險

團隊一般有兩個 npm/Yarn 包更新策略：（1）儘快更新，甚至使用自動化流程（2）根本沒有更新策略，有時候會根據口碑進行更新。 雖然第一種方法彷佛更優越，但使人驚訝的是它是 2018 年最危險的方法：社區在 40 天內發現的全部諸如平流等惡意包，處於等待狀態以及更新不快的包都被保存了。 考慮使用自動化工具格式化更新策略，並找到」徹底不更新「到」正在更新「過程之間的位置。

例子：

• Liran Tal 的 npq 是一個很棒的諮詢包安裝器，它也關注發佈日期

• 一旦包更新，greenkeeper 等商業工具將馬上 PR。 不過在發佈版本被證明安全以前，沒有人可以暫停更新

12. 執行逐步安裝，區分部署和發佈階段

2019 年，你可能會發現執行更安全的部署很是有用，這些部署不是一錘子買賣。在更安全的方面，粒度部署（a.k.a canary）建議分爲 3 個階段：（1）部署 - 將新代碼發送到隔離的新生產區域（例如，新的 Kubernetes 服務或機器實例）。在這個階段，它爲任何人服務，因此沒必要懼怕（2）測試 - 如今不多有人能夠在最現實的生產環境中開發和測試新代碼（3）發佈 - 逐漸容許更多用戶發佈新版本（例如，整個東海岸），等你有了足夠的信心，你能夠淡出舊版本。

須要注意的是：2019 年進行全面的灰度部署仍然很是昂貴，由於它須要協調許多基礎設施部件，如路由和監控。所以，請考慮從簡單和半手動灰度部署開始（例如，根據監控指標手動啓動更多新版本機器）

例子：

• 瞭解有關灰度版本的更多信息

• 若是你願意一直跟進到灰度部署，Spinnaker 是一個強大的部署平臺

13. Kubernetes 吃了這個世界

Kubernetes（K8S），它是無縫提供網絡，橫向擴展，部署和其餘骨幹服務的應用組件的基礎架構，如今幾乎是託管應用的事實標準。它的受歡迎程度十分驚人：在全部雲供應商的支持下，擁有無與倫比的擴展回聲系統，即便 54％ 的企業已經擁有至少一個 K8S 集羣。若是你是初學者，此連接提供了一個很好的動手概述。你的 K8S 第一步已經完成了嗎？確保熟悉 Istio，K-Native，Kuberenes 工做，內部概述，網絡政策，Helm，Scaffold。總的就一句話：你花在加深 K8S 技能上的任什麼時候間都會獲得回報。

14. 區塊鏈技術帶來了一些很好的機會

除了比特幣和加密功能，區塊鏈也能夠用於任何分佈式系統處理事務。

15. 得到可靠的機器學習技能，或者至少可以聰明地闡述

這個我說不了太多，它也許是咱們時代的主導趨勢。惋惜，我對機器庫一無所知，我對 2019 的目標是至少可以聰明地談論它，並找出快速獲勝的機會（例如，像 tensorflow.js 和 brain.js 這樣的 JS 庫能夠在沒有強大的基礎設施的狀況下提供一些幫助）

16. 瀏覽所選開源庫的代碼

注意，使用相同的技術長時間開發同一個項目上，可能會限制你的視野或錯過不少替代方案。努力常常調研其餘項目，主要是成功的開源項目。

17. 深化對 Linux 操做系統的理解，重點關注 Linux 進程的解剖

瞭解 Linux 進程將給予你真正的競爭優點，由於它會影響許多開發任務，如監視，保護進程（例如從新啓動），使用 Docker 優雅地關閉以及許多其餘任務。努力瞭解流程，信號，權限模型，經常使用命令，流程類型等的生命週期。本教程涵蓋了大多基礎知識。

18. 深刻了解 Node.js 內部原理

我真的很喜歡 Ryan Dahl（Node.js v0,1的創造者）的一句話：「你永遠沒法理解一切。可是，你應該讓本身去了解系統「。當須要處理生產問題或設計一些基礎結構組件（例如監視事件循環性能）時，對底層機器的深刻理解會顯得頗有價值。你可能已經熟悉了 v8 和 libuv 等核心構建塊。難道 2019 不是深刻 Node.js 兔子洞（譯者注：《愛麗絲夢遊仙境》的兔子洞）之旅的好時機嗎！例如，瞭解每一個 libuv 事件循環週期內究竟發生了什麼？或者瞭解如何與操做系統 IO 交互（例如活動句柄）？

例子：

• 瞭解每一個事件循環週期中發生的事情，由 Deepal Jayasekara 提出

• 瞭解如何將 C/C++ 代碼打包爲 NPM 模塊，由 Konstantin Tarkus 提出

• 訪問這篇由 Eugene Obrezkov 撰寫的涵蓋整個 Node.js 內部的深度文章

19. 壓軸：學習使用科學方法

你學到的東西和內化將塑造你將來的職業生涯。然而，許多開發人員既沒有學習策略，也不知道如何使用科學方法有效地學習。假設有個關於「避免 JavaScript 類型錯誤」的會議，VP 要求繼續使用原生 JavaScript 而不重構整個代碼庫（不使用 TypeScript ......），忽然間你的同事建議使用 Facebook 流程，房間裏的每一個人都喜歡它！你忽然想起你曾經讀過它，但它歷來沒有被內化爲你的只是，只是在你的腦海中溜過。爲何會這樣？顯然，有一種名爲「競爭幻覺」的現象解釋了爲何咱們會忘記這些事情：你可能花了 1 個小時閱讀一篇博文，可是你自欺欺人，幾天以內就不記得了！研究代表，若是你稍後嘗試與人談論它，或者在次日再次閱讀摘要，你就能夠大大提升記憶這個概念的機會。還有其餘各類技巧能夠幫助你在正確的時間記住並獲取正確的知識（參見下面的示例），花幾個小時學習如何學習，對你的職業生涯大有裨益！

例子：

• 參加《學習如何學習》這個超棒的課程

• 在學習時進行分塊和分類

• 學習新技術的時候呢？將它與你熟悉的現有事物相比較，與你的隊友談論它，問問本身「這有什麼用」的問題 - 爲何須要它，繪製圖表，從新閱讀摘要，幫助你的大腦內化並對其進行分類，如此你將可以在重要的狀況下得到它！

英文原文：

https://medium.com/@me_37286/19-ways-to-become-a-better-node-js-developer-in-2019-ffd3a8fbfe38

好文推薦：

Node.js 基金會和JS 基金會準備合併，你怎麼看？

「UC國際技術」致力於與你共享高質量的技術文章

歡迎關注咱們的公衆號、將文章分享給你的好友