原文作者：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
好文推薦：
“UC國際技術”致力於與你共享高質量的技術文章
歡迎關注我們的公眾號、將文章分享給你的好友