Node.js開發技能有哪些

這篇文章給大家分享的是有關Node.js開發技能有哪些的內容。小編覺得挺實用的，因此分享給大家做個參考。一起跟隨小編過來看看吧。

1. 增加類型和模式——TypeScript 是 2019 年的一個非常好的候選項

事實證明，無類型編碼不僅效率不高，而且容易出錯。但這并不意味著你一定要使用嚴格的類型語法，你可以根據實際情況選擇類型的嚴格程度，比如使用 JSON Schema 或 Joi 來驗證實體和模型，或者用靜態類型來注解 JS（請參考 https://github.com/facebook/flow ），或者使用全類型的 TypeScript。

TypeScript 在 2018 年取得了顯著的進展，似乎已經進入了 Node 領地。如果你計劃使用 TypeScript，那么應該問一下自己，你是否只是想要使用它的類型功能，如果也要使用接口和抽象類，那么可能需要學習新的編程范式。

2. 豐富你的 linter

linter 實際上是免費的午餐，只需要 5 分鐘的設置，就可以免費獲得自動代碼保護，并在輸入代碼時發現重大問題。認為 linting 只是花拳繡腿的日子已經一去不復雜了。如今，linter 可以捕獲嚴重的代碼問題，例如錯誤沒有被正確拋出、丟失信息、沒有完成的 promise，以及其他你從未真正想要留在代碼中的錯誤。

3. 更多的 Java 和更少的 Ruby——加深你的架構知識

有關 NodeJS 生態系統的架構和設計方面的知識并不多，每個人都在談微服務，但只談到了一些內部結構。因此，大多數應用程序和示例都是基于 MVC 概念以及一些來自 Ruby 的其他模式。這有什么問題？MVC 適用于構建內容服務，但在構建健壯的后端方面差強人意。你可以用兩個類——Controller 和 Model 來描述你的整個業務邏輯、規則、數據訪問、與其他微服務的通信嗎？

我絕對不建議采用重量級的 Java/Spring 模式（所以我們才會來到 Node 的領地，不是嗎？），而是選擇一些能夠提供價值卻不會犧牲應用程序簡單性的想法。

4. 計劃如何利用 Async Hook 來獲得更好的跟蹤和上下文

單線程模型有一個缺點——請求會丟失上下文：當它們流經多個文件并執行異步操作時，變量在整個生命周期中不會被保留。為什么這個很糟糕？例如，開發人員通常希望在每個日志條目中包含唯一標識符，以便稍后可以關聯同一請求的所有日志條目——在 2018 年實現這個并不是很容易。

2019 年將會有新的東西出來，Async Hook 就是其中之一（不是全新的特性，但很快就會結束實驗階段）——簡單地說，這是一種在異步操作開始和結束時隨時注入自定義代碼的機制。這樣就可以關聯同一請求的所有代碼并保留上下文。這為很多自定義程序包奠定了基礎，這些程序包將 Node 的跟蹤和上下文能力提升到了一個新的水平。

5. 了解最新的“Serverless”

注意：這里將 FaaS 和 Serverless 這兩個詞互換使用，盡管它們并不完全相同。

最初，FaaS 用于微任務的開發，而不是用于“微服務”應用程序。隨著它們受歡迎程度越來越高，云供應商的胃口也越來越大，很快，新功能開始堆疊起來，到了 2019 年，它似乎變成了強大的應用程序基礎設施。

它現在可以與 Kubernetes 展開競爭并為大型應用程序提供服務嗎？有些人認為 Serverless 和 FaaS 是正交技術，但實際上，2019 年的每一個新的云應用程序都必須選擇三者中的一個：裸機實例（如 EC2 或 GCP 計算）、Kubernetes 或 FaaS。因此，了解 K8S 和 FaaS/Serverless 并知道它們之間的區別將成為一項必備的設計技能。

6. 了解最新的 JavaScript 特性

我并不是一個只顧追求每一個語言新特性的狂熱粉絲，有時候，這些閃亮的玩具會違背代碼的簡單性原則。一些真正有價值的 JavaScript 特性會隨著時間沉淀下來（比如兩年前引入的 async/await），所以 TC39 提案列表和 node.green 值得一探究竟。

7. 熟悉至少一種 API 技術——GraphQL 是 2019 年的一個很好的候選項

REST 風格的 API 與它的設計目標相得益彰：可以很好地控制實體的修改和查詢。假設你有一個財務記錄系統，你可能希望設計非常嚴格的端點，即單個顯式數據模型。然而，在其他非常常見的場景中，REST 表現不足，比如執行一系列可能返回不同數據集的查詢、需要最小化 API 有效載荷的低帶寬網絡、強調速度的機器到機器通信，等等。那么是否應該換成其他的？當然不是，你可以選擇混合使用。API 并不是架構，它們只是應用程序的端口（即入口點），并且多種 API 樣式可以共存，甚至是在單個 Web 框架之上，如 Express。

那么要學習哪一個？你最好的選擇可能是 GraphQL，它正在成為主流。它的生態系統已經非常成熟，可以提供非常流行的用例，如動態搜索和層次數據源。另一方面，gRPC 仍然是一種適用于服務器到服務器間通信的小眾技術，因為其開銷非常小（例如用于 Pub-Sub/ 消息隊列系統）。

8. 超越單元和集成測試

你已經對測試金字塔、單元、集成和端到端測試很熟悉了？很好，這些是成功測試策略的基礎。在過去的 10 年中，開發領域發生了巨大的變化，但測試模型幾乎保持不變，于是我們不禁想知道如何測試像微服務、豐富的前端和 Serverless 這樣的東西。一些現代技術與傳統技術棧相輔相成，有時候甚至可以替換它們，以便實現更精簡的測試策略，獲得更高的投資回報率。

9. 在監控中遵循 SRE/DevOps 最佳實踐

2019 年，即使是一個中型應用程序也可能包含數十個移動部件。然而，大多數開發人員沒有花心思去學習由 SRE 工程師教給他們的監控和警報方面的知識。例如，開發人員通常會優先考慮并專注于 CPU 和內存等內部硬件指標，而不是去考慮會直接影響最終用戶體驗的指標，例如錯誤率或延遲。這些面向客戶的指標有時候被稱為“黃金信號”，而在 2019 年，你可能希望從關注這些指標開始，并采用類似的最佳實踐。

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

如果你不能像攻擊者那樣思考，也就無法像防守者一樣思考。2019 年，你不應該將防御工作外包給第三方公司或只依靠靜態安全掃描程序：攻擊類型的數量非常之多，應用程序發生變更的速度是不可控的——在開展安全研討會兩天之后，團隊有可能又添加了幾個新的 AWS 服務、數據庫類型和新的 IAM 角色……因此，開發人員其實是最大的隱含威脅，教育他們似乎是最終的補救措施。你必須將安全 DNA 根植到你自己和團隊中，并為所有東西添加安全保護。

當你開始這么做之后，事實證明，安全問題并不沒有那么可怕。你只需熟悉常見的攻擊類型和工具，畫出應用程序架構和流程，并想想你自己會如何攻擊它。隨著時間的推移，在不知不覺中，你將在做出每個設計決策和編寫每一行代碼時考慮安全問題。

11. 制定包更新策略

2018 年的教訓：過早更新可能很危險。一個團隊通常會使用這兩個包更新策略中的一種：一個是盡快更新，有時甚至使用自動化流程。一個是根本沒有更新策略，有時候是看心情進行更新。雖然第一種方法似乎更好，但令人驚訝的是，它在 2018 年成為最危險的方法：在 40 天之內，社區就發現了好多個惡意包事件，如 flat-stream，那些在等待或沒有進行更新的人反而平安無事。可以考慮使用自動化工具正式化更新策略，并找到不更新和更新之間的最佳平衡點。

12. 進行漸進式安裝，將部署和發布階段分開

2019 年，你可能會發現進行更安全的部署非常重要，也就是不一次性推出到所有的生產環境，然后讓你的小心臟像錘子一樣砰砰跳。進行細粒度部署（也就是金絲雀部署）可以分為 3 個階段：部署——將新代碼發送到隔離的新生產環境（例如新的 Kubernetes 服務或新的機器實例）。在這個階段，它不為實際用戶提供服務，所以沒有什么可擔心的。測試——現在有少數人可以使用生產環境的實例，并測試新代碼。發布——逐步允許更多的用戶使用新版本，在你有足夠的信心后，可以下架舊版本。

需要注意的是：進行全面的金絲雀部署在 2019 年仍然是非常昂貴的，因為它需要協調很多基礎設施部件，如路由和監控。因此，請考慮從簡單和半手動金絲雀部署開始（例如根據監控指標手動啟動更多部署了新版本的主機）。

13. Kubernetes 正在吃掉這個世界

有一個很明顯的趨勢：Kubernetes（K8S），一個為應用程序組件提供網絡、橫向擴展、部署和其他骨干服務的基礎設施，現在幾乎是托管應用程序的事實標準。它的受歡迎程度是非常驚人的：在所有云供應商的支持下，擁有無與倫比的擴展生態系統，54％的企業已經擁有至少一個 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 原始作者）講的一句話：“你不可能理解所有的東西。但是，你應該讓自己去了解系統”。當你需要處理令人頭疼的生產環境問題或設計一些基礎設施組件（例如監控事件循環性能）時，對底層機器的深入了解被證明是有價值的。你可能已經熟悉了 v8 和 libuv 等核心構建塊。

那么 2019 年是深入了解 Node.js 的好時機，例如，了解每個 libuv 事件循環周期內究竟發生了什么？或者可以了解與操作系統 IO 的交互是如何進行的（例如活動句柄）？

19. 學習使用科學的方法

你學到的和內化的東西將塑造你未來的職業生涯。然而，很多開發人員既沒有學習策略，也沒有學習如何使用科學的方法進行有效的學習。

在一個關于“防止 JavaScript 類型錯誤”的會議上，VP 要求繼續使用 JavaScript 而不重構整個代碼庫（不使用 TypeScript……），突然你的一位同事建議使用 Facebook Flow，房間里的每個人都表示贊同！你突然想起你曾經看到過有關它的文章，但它從來沒有被你內化，只是在你的腦海中一閃而過。

這是怎么回事？

顯然，有一種叫作“競爭幻覺”的現象解釋了為什么我們會忘記這些東西：你可能花了 1 個小時閱讀一篇博文，但在幾天之內就不記得了！研究表明，如果你稍后嘗試與某人說起這些東西，或者在第二天再次閱讀文章摘要，就可以大大提高記憶成功率。當然，還有其他各種技巧可以幫助你在正確的時間記住并獲取正確的知識。花幾個小時學習如何學習可以為你的職業生涯帶來很大的幫助！

感謝各位的閱讀！關于Node.js開發技能有哪些就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！