2019 年(大)前端技術規劃

收藏待读

2019 年(大)前端技術規劃

新的一年裡,有些新的技術會從實驗走向試用;有些技術,則會從試用走向採用;有些技術,則會從採用走向棄用。若是以此為出發點,那麼這個 2019 年和過去的 2018 年相比,並不會有太大的區別。學一些新的技術,忘掉一些不同使用的技術。只是前端一個這麼廣的領域,到底要關心什麼技術,到底要忽略什麼技術呢?

這便也是我寫下這篇文章的意義。可是呢,在寫作的過程中:「不行啊,我光告訴你 2019 將會流行什麼,可能並沒有多大的意義。你們需要自己去學會擁有這樣的技能,學會去分析出 2020 需要規劃什麼內容。」

於此,本文便分為了兩部分,如何做前端規劃以及 2019 年我們需要什麼。

技術規劃

W-H-Y

每每談到技術規劃,我們談的總是下一年、下一個階段、下一個五年的目標。可為什麼我們需要做技術規劃?或許是出於 KPI 的影響,或者是出於預算的原因,或是在追求技術卓越。

我們的目的是: 變得更好 。於是乎:「為什麼我們就不能使用現在的架構?現在的架構不是挺好的嗎??」

為此,我們只需要嘗試回答這麼幾個問題:項目的編譯速度快嗎?編寫新功能的速度快嗎?能滿足快速上線的需求嗎?多個團隊並行開發,會出現問題嗎?我們依賴的第三方組件,會出現問題嗎?……

嗯,對這個問題就好像,別人在問你,「你有什麼不足?」。

HOW

從這篇文章的寫作過程,及筆者的相應規劃步驟來看,可以分為這麼幾步:

  1. 調研技術遠景
  2. 從社區獲得相應的輸入
  3. 整理潛在的技術方案、架構、技術棧
  4. 從利益相關者獲得想法。
  5. 制定相關的實施計劃

規劃,它類似於技術遠景的味道。可一談到遠景,那麼要談論的東西可多了。說不到我們還需要尋找利益相關者——如團隊成員、項目領導,了解一下,他/她對於技術團隊的一些期望。我們在社區上看到相似的問題,總有一個相似的開頭:「我們的領導……。」

談理想都特別有意思,因為我們不一定會去做。我們有了一個宏大的想法,只是受限於多個因素,我們只能做這麼一點。比如說,我們未來想造一個筆記本,那麼現在我們可以只選一個螺絲釘。

而在我們獲取更進一步方向的時候,需要從這麼幾個維度來考慮問題:

  • 從業務現狀出發 。譬如,在下一年裡,我們的團隊將從 20 人擴大到 100 人,為了支撐這麼大的團隊。我們需要擁有培訓機制,來應對這樣的人員擴張;需要設計一個更好的架構,來實現多個團隊的並行開發。
  • 從技術、架構出發 。在項目中引入新的技術,改進原有的技術方案。
  • 架構的預研 。提前試用未來可能使用的技術,如 AR、VR。這些往往是一些非必需的規劃,但是有了它們會更好。
  • 團隊能力規則 。談論到團隊規劃,我怕是並不是那麼擅長。大抵上,哪怕是技術負責人也不是 KPI 的制定者,我們只能談談理想,聊聊團隊建設的一些建議。有針對性地培養項目的 2nd Tier,至少對方是否能接受,那便不在我們的控制之下。這大抵也是個人發展的好處,可以選擇自己感興趣的內容學習。

當然了,其它相當多的東西,還是要落地的——我們還是得造螺絲釘。只有落地的東西,才能證明它是真正有價值的東西。為此我們要用 SMART 原則制定一個 smart 目標。當然了,如果你還要對領導彙報,請不到忘了你的時間節點。

總之,保持現在,探索擴展,嘗試未來。

!WHAT

是不是我們規劃每件的事,都值得去做?是不是我們只做規劃的事情?未來是一直在發生變化的。而規劃,只針對我們知道的內容提出的。它無法用於我們不知道的領域。它也無法應對未知的事務,如產生了一個新的技術,它提高了三倍的生產力。那麼,先前我們設計的一些規劃,可能在此被新的技術替代掉了。

這方面的實踐,便有點類似於演進式架構的味道。我們定好了一個大體的目標,核心的部分,只在真正實現的時候完善。為此,它需要具備一定的可演進式,也因此不會受過去的設計所限制。倘若基於這一點因素考慮,那便是容易得多了。只需要去尋找那些真正可能影響我們的趨勢,套上一個模糊的概念,就可以這麼輕裝上陣。

可是呢,在做這件事情的時候, 每個人心裏都有了一個答案 。事實上,你心底也已經有了一個答案,只是說呢,你不敢、不想直接說出自己的想法——一來,受限於能力;二來,怕做了錯誤的決定。而直接、間接地,你在社區上看到一個大佬的回答,與你想要的答案是類似的。便將這個答案懷chen出來,信心也就有了,再說 「我們也可以這麼搞」。好了,以後一旦出現了問題,還有一個人可以莫名地幫你背鍋。

大家活着都不容易,背鍋事小,不帶人身攻擊就好。責任,它與能力和屁股的位置是成正比的。

前端 in 後端

所謂的前端 in 後端,便是 在後端開發中,使用前端相關的語言和技術棧 。最典型的場景,便是使用 Node.js 開發後端服務。雖然 Node.js 已經有了 10 年的歷史了,但是以我(Phodal)的角度來看,我更希望的是使用編譯型語言,來開發後端服務。動態語言,無法使用編譯器來檢測錯誤,難以約束代碼變動。

Node.js 打造後端服務

從社區的探索來看,存在一些完全使用 Node.js 開發的後台服務。但是,也存在一系列由於代碼不規範造成的問題。從社區的經驗來看,Node.js + Express + MongoDB + Angular/Vue/React,便是一些不錯的選擇。當然了,也有相當多的應用,只是採用了 Node.js 來完成 BFF 層(Backend For Frontends)。在這一層業務上,它只做業務數據的中間處理。

雖然,我經常建議在一些關鍵的節點上,不要採用 Node.js 來打造後台服務。可一旦涉及到 SPA 的服務端渲染,我們就不得不使用 Express、Koa 等這樣的服務端 JavaScript/TypeScript 框架,來解決這樣的問題。

Serverless

作為一種折中方案,也是我最喜歡的方案。Serverless 架構是指大量依賴第三方服務(也叫做後端即服務,即「BaaS」)或暫存容器中運行的自定義代碼(函數即服務,即「FaaS」)的應用程序,函數是無服務器架構中抽象語言運行時的最小單位。

採用 Serverless 架構,也就意味着,我們提取出了大量的基礎設施。而使用 Node.js + JavaScript 作為膠水,來快速連接不同的服務,以形成一個快速有效的方案。並且,編寫更少的代碼,也意味着更安全、快速。

除了直接基於 AWS 的 Serverless Framework 框架的方案,還有 OpenFaaS、Kubeless、OpenWhisk、Fission 等不同的 Serverless 框架。

前端架構

由於前端的代碼量在不斷地增加,前端不在是一個大泥球架構,越來越多的新架構,將出現在前端領域。

微前端架構

微前端是一種類似於微服務的架構,它將微服務的理念應用於瀏覽器端,即將 Web 應用由單一的單體應用轉變為多個小型前端應用聚合為一的應用。各個前端應用還可以獨立運行、獨立開發、獨立部署。

從筆者在 2018 年的實踐經歷來看,微前端架構確實是一個不錯的架構方案。它能有效地解決臃腫前端應用、遺留前端應用和複雜前端應用。我們在項目上嘗試使用了多種不同的實踐方式:微件化、微應用化、路由分發、前端微服務化等。將一個應用分解,拆解成更多的應用,確實能相對高效地提升開發效率。

如果你們的應用已經相當的大,記得採用微前端相應的技術。還有閱讀我寫的《微前端的那些事兒》。

組件庫及設計系統

自 Ant Design 的聖誕節事件之後,我相信: 在 2019 年,有越來越多的團隊將構建自己的組件庫 。一種頗為簡單的方案,便是:

  1. 評審一個開源組件庫 Ant Design、Material Design 等
  2. 在開源組件庫的基礎上,進行二次封裝。如 變成
  3. 替換部分的開源組件代碼

隨後,在那些的基礎上,加入自己的模式庫和設計系統。

BFF 架構

有越來越多的系統中,出於應對多端(Android、iOS、Web)變化的考慮,便在後端做數據相關的處理工作。為了更好的解耦業務邏輯,並提供更快的業務響應,便在這一層級採用了 BFF 架構。BFF 全稱是 Backends For Frontends (服務於前端的後端),它是指在設計 API 時根據不同的設備類型,來返回不同的結果。

除了,採用 Node.js 中相應的後端框架,作為 BFF 層的開發模式。GraphQL 是在 2018 年特別流行的一種 BFF 模式,毫無疑問在 2019 年也是一個值得考慮的方案。

HTML 5 大型遊戲

隨着移動端的性能不斷變好,在 2019 年,我開始看好使用 HTML 5 技術來開發一些遊戲。當然了,主要原因還是微信小遊戲的出現。但是,不管怎樣,我開始嘗試在這個領域的探索。

前端 in 前端

前端領域,在 2018 年已經趨於平衡,Angular、Vue、React 都沒有出現太大的變化。

框架

架構選型上,也趨勢於平衡。該用啥的還是用啥,偶爾還是會出現一些框架切換的新聞。儘管在 2019 年,會出現一些新的框架,但是還不太可能快引起變化。

TypeScript

TypeScript 真香。

前端,沒什麼好看——除了,娛樂新聞。

前端 in IoT

從 2018 年的趨勢來看,至少物聯網會在 2019 出現一定的上升趨勢。目前的主要表現階段,是在智能家居相關的領域。如果只是就一領域而言,那大抵還是不錯的。

筆者在撰寫《自己動手設計物聯網》時,使用的技術便是 JavaScript 作為後端和 Web 前端、移動應用的開發技術。而無疑的物聯網領域,除了現有的 Web 領域,還有各個地方都可以使用 JavaScript 作為開發語言。

  • 嵌入式 UI 界面。對於處理器資源豐富的設計來說,它們可以採用完整的瀏覽器來運行前端應用,而不再是裁剪過的引擎。
  • 智能音箱。在過去一年裡,已經成為了一個新的入口了。而諸如 AWS Alexa 等都可以採用 Node.js 來開發語言技能。
  • 嵌入式開發語言。諸如可以使用 JavaScript 作為開發語言的 IoT.js。事實上,它會變成類似於 Emacs 架構,由原生來實現編譯器,由動態語言來增長特性。
  • ……

你覺得呢?

開發工具完善

開發工具的完善,一直在每年的規劃里。在 2019 年裡,也是如此,引入更好的工具,如更好的拖拽工具,更好的代碼生成工具——由 AI 生成。

前端 in mobile

前端 in mobile,指的是用前端的技術來開發移動應用。

RN 及 Flutter

依我的角度來看,使用什麼跨平台框架來看,區別並不是太大。目前主流的方案,仍然是原生(含跨平台框架) + HTML5 應用。從業務的角度上來看待這個問題,那麼還是希望,可以用 HTML 5 的地方多——更新功能方便。

也因此,雖然在過去,筆者寫過基於 React Native 的混合應用框架 Dore。我相信:Flutter 也會出現這樣的混合應用框架。不過,對於有原生開發能力的團隊來說,它們的框架還會是三部分:

  • 原生功能部分
  • 原生 + H5 的頻繁更新部分
  • Fultter 的跨平台部分

寫業務嘛,框架都只是工具。

小程序

小程序,即 HTML5 小程序,即無需安裝即可下載運行的應用程序。與普通的移動 Web 應用不同的是, 小程序相當於是高階版的混合應用

如果只是從這一點上來看,其實是不是和微信一樣的定製型小程序,並不是那麼重要。重要的,在於與原生 界面結合,並提供離線使用功能。 它也是小程序與普通的 HTML 應用的區別。

安全

從 2018 年的前端社區經驗來看,NPM 包的安全,也成為了一個值得考慮的問題。

也因此 2019 年,也不得不進行相應的安全機制的設計。

也因此 2020年,也不得不進行相應的安全機制的設計。

也因此 2021 年,也不得不進行相應的安全機制的設計。

……

原文 : Phodal全棧工程師

相關閱讀

免责声明:本文内容来源于Phodal全棧工程師,已注明原文出处和链接,文章观点不代表立场,如若侵犯到您的权益,或涉不实谣言,敬请向我们提出检举。