前端技術雷達最新動向:微前端可採納,10倍工程師要暫緩

技術雷達是 ThoughtWorks 每半年發佈一次的技術趨勢報告,迄今已經走過 10 年,累計發佈 21 期。在最新一期的技術雷達中,我們摘取了前端領域值得關注的技術、平臺、工具、語言 & 框架的趨勢和走向。從可採納、可實驗、待評估、需暫緩四個象限來看,一些結論值得關注:微前端進入可採納清單,10 倍工程師進入需暫緩清單。

可採納清單

技術

Micro frontends

引入微服務令我們受益匪淺,使用微服務,團隊可以擴展那些獨立部署及維護的服務的交付。遺憾的是,我們也看到許多團隊創建了單體前端——一個建立在後端服務之上的大而混亂的瀏覽器應用程序——這在很大程度上抵消了微服務帶來的好處。自從問世以來,微前端持續變得流行。我們已經看到,許多團隊採用這種架構的某種形式來管理多開發人員和多團隊的複雜性,以提供相同的用戶體驗。今年六月,這項技術的發起人之一發表了一篇介紹性的文章,可以起到微前端參考文獻的作用。它展示了這種設計是如何通過各種 Web 編程機制實現的,並使用 React.js 構建了一個示例應用程序。我們有理由相信,隨着大型組織嘗試在跨多團隊中分解 UI 開發,這種風格將越來越流行。

工具

ESLint

作爲 JavaScript 的代碼檢查工具,ESLint 提供了很多規則集、推薦規則和插件,可以擴展爲不同的框架或 JavaScript 風格。我們發現,通過在開發時對代碼進行實時分析,Eslint 可以極大地幫助團隊在開發過程中建立和遵循代碼規範。Eslint 不僅可以通過實施最佳實踐和代碼規範,對編碼實踐進行標準化,還能識別代碼中的漏洞。這是因爲 ESLint 與大多數 IDE 都能很好地集成,並可以在編碼過程中提供實時反饋。特別是它的樣式規則可以自動修復代碼錯誤,持續有效並且不會產生額外的開發成本。ESlint 社區的文檔很好地解釋了它的編碼模式,可以幫助開發人員快速掌握規則。隨着 ESLint 變得越來越通用和強大,它已經被行業所認可。例如 TypeScript 團隊就選擇支持 ESLint 並與其合作,而非 TSLint。

React Styleguidist

React Styleguidist 是 React 組件的開發環境。它提供帶有熱重載功能的開發服務器,並可以生成 HTML 樣式指南以便與團隊進行共享。這個樣式指南可以展示所有組件的最新版本,以及組件的使用文檔和參數列表。我們之前在 UI 開發環境中介紹過 React Styleguidist。而現在,相比於其他類似工具,React Styleguidist 已成爲我們的默認選擇。

可試驗清單

技術

Zhong Tai

近年來,中臺一直是中國 IT 界的流行語,但它尚未在西方國家流行起來。中臺的核心是提供封裝業務模型的方法。它旨在幫助新的小型企業提供一流的服務,而無需傳統企業基礎架構的成本,並使現有組織能夠以驚人的速度將創新服務推向市場。中臺戰略最初是由阿里巴巴提出的,並很快被許多中國互聯網公司所採用,因爲它們的商業模式是數字原生的,可以複製到新的市場和領域。如今,越來越多的中國公司將中臺作爲數字化轉型的槓桿。

工具

Figma

交互和視覺設計的一大痛點是缺乏用於協作的工具,Figma 就是爲此而生的。它不僅具有與 Sketch 和 Invision 等設計程序相同的功能,而且還支持與其他人實時協作,幫助多人一起探索新的想法。我們的團隊發現 Figma 非常有用,特別是它支持與簡化了遠程和分佈式的設計工作。除了協作功能之外,Figma 還提供了有助於改善 DesignOps 流程的 API。

Loki

Loki 是一個配合 Storybook 使用的可視化迴歸工具,我們在 UI 開發環境中提到過 Storybook。只需幾行配置,就可以使用 Loki 測試所有 UI 組件。推薦在 Docker 容器中使用 Chrome,以避免在不同的環境中運行測試時出現的 1 像素差異問題。我們的經驗是測試非常穩定,但是 Storybook 的更新往往會由於細微的差異而導致測試失敗。Loki 似乎也無法測試使用 position:fixed 的組件, 但可以使用 fixed 包裝組件來規避這個問題。

語言 & 框架

Arrow

Arrow 是適用於 Kotlin 的函數式編程庫,是由兩個現有流行庫(kategory 和 funKTionale)合併而成。雖然 Kotlin 爲函數式編程提供了構建模塊,但 Arrow 爲應用程序開發人員準備了隨時可用的高級抽象包。它提供數據類型、類型類、作用(Effects)、Optics 和其他函數式編程模式,並且可以與流行庫相集成。我們對於 Arrow 最初的好印象如今已經在生產環境的應用構建中得到 了印證。

Flutter

我們的一些團隊使用了 Flutter 並且很喜愛它。作爲跨平臺框架,它可以幫助我們用 Dart 語言編 寫原生移動應用。藉助 Dart,Flutter 可以編譯成平臺原生代碼並直接和目標平臺通訊,從而避免了橋接和上下文切換。Flutter 的熱重載(hot-reload)特性亦讓人驚歎,它能在編寫代碼時提供超快的視覺反饋,我們推薦你在項目中嘗試使用 Flutter。

jest-when

jest-when 是一個輕量級的 JavaScript 庫,通過匹配模擬函數調用的參數完善了 Jest 的功能。Jest 是測試整個技術棧的好工具,而 jest-when 可以幫助檢查模擬函數接收的參數。這樣就能夠爲具有很多依賴的模塊寫出更強壯的單元測試。

React Hooks

今年年初,React Hooks 成爲了流行的 JavaScript 框架。它無需編寫類就可以使用狀態和其他 React 功能,從而提供了一種比使用高階組件或 render-props 更簡潔的方法。諸如 Material UI 和 Apollo 之類的庫已經切換到使用 Hooks 了。測試 Hooks 時會遇到一些問題,特別是使用 Enzyme 時,這能幫助我們重新評估是否選擇 Enzyme 作爲工具。

React Testing Library

JavaScript 世界日新月異,隨着我們在框架使用方面的經驗越來越多,我們的推薦也隨之改變。有些框架隨着我們的深入使用,會讓其他類似框架黯然失色。在 React 前端測試方面,React Testing Library 就是這樣一個例子。用它寫的測試比其他框架(如 Enzyme)脆弱,因爲它鼓勵獨立測試組件間的關係,而不是測試全部實現細節。

Styled components

使用帶標籤的模板文字 styled components,可以將爲 React 組件設置樣式所需的 CSS 直接放入創建該組件的 JavaScript 代碼中。這大大減輕了管理 CSS 的痛苦,並且不需要爲避免 CSS 中的命名衝突而想盡辦法,比如命名約定等。開發人員在查看組件定義時可以直接看到樣式,而不必記住幾 MB 的 CSS 樣式。當然,將 CSS 放入 JavaScript 代碼中,可能會使跨不同組件樣式的一致性變得更加困難,因此我們建議使用這種方法時一定要理解其優缺點。

待評估清單

技術

JAMstack

許多年前從手機原生開發興起的後端即服務開發模式,現在在 Web 開發上變得流行起來。我們將這種集合了靜態站點生成和利用第三方 API 進行客戶端渲染的框架被稱爲 JAMstack(JAM 代表 JavaScript、API 和 Markup),例如 Gatsby.js。這種方式之所以能給用戶提供豐富的體驗,主要依靠的是 API 和 SaaS。因爲 HTML 不管是在網頁瀏覽器中還是在構建時渲染,它的部署模型和全靜態生成的網站是一樣的,共同的好處是服務端的攻擊面很小,而使用很少的資源可以獲得極好的性能。事實上,像這種在部署上對內容發佈網絡(CDN)非常友好的技術,我們開玩笑想把它稱爲 CDN 優先應用程序。

平臺

GraalVM

GraalVM 是一種由 Oracle 開發的通用虛擬機,用於運行基於 JVM 的語言,JavaScript、Python、Ruby、R 以及 C/C++ 等其他基於 LLVM 的語言編寫的應用程序。簡單地說,GraalVM 可以用作 VM 和其他所支持的非 JVM 的語言的高性能虛擬機。但它也允許我們編寫多種語言的應用程序, 而且對性能影響很小。它的原生鏡像程序 (當前僅可作爲早期採用者的技術使用)讓我們可以提前將 Java 代碼編譯成獨立的可執行文件,從而加快啓動速度並減少內存的使用。GraalVM 在 Java 社區引起了巨大的反響,並且許多 Java 框架(包括 Micronaut 、Quarkus 和 Helidon)已經在利用它的技術了。

語言 & 框架

KotlinTest

在 Kotlin 生態系統中,KotlinTest 是我們團隊喜愛的獨立測試工具。它提供了我們在之前的雷達中強調的技術——基於屬性的測試。它的關鍵優勢在於提供了多種測試方法以構建測試套件。同時,它內置了一組全面的匹配器,使我們能用優雅的內部 DSL 編寫富有表現力的測試。

NestJS

NestJS 是使用 TypeScript 編寫的服務器端框架。通過集成 Node. js 社區的豐富生態,NestJS 提供了一種開箱即用的應用程序架構。開發 NestJS 的思維模型類似於 Angular 的服務器端版本或 Spring Boot 的 TypeScript 版本,因此開發人員的學習曲線很低。NestJS 支持諸如 GraphQL、Websocket 和 ORM 庫之類的協議。

SwiftUI

蘋果在其新的 SwiftUI 框架上邁出了一大步,該框架用於在 macOS 和 iOS 平臺上實現用戶界面。我們很高興 SwiftUI 跨越了 Interface Builder 和 XCode 之間略顯混亂的關係,並採用了一致的、聲明性的和以代碼爲中心的方式。現在,你可以在 XCode 11 中並排查看代碼和生成的可視化界面,從而獲得更好的開發人員體驗。SwiftUI 框架還從近年來主導 Web 開發的 React.js 的世界中汲取了靈感,它利用視圖模型中的不可變值和異步更新機制,構成了統一的反應式編程模型。這爲開發人員提供了一個完全原生的替代品,以替代類似 React Native 或 Flutter 之類的反應式框架。儘管 SwiftUI 確實代表了 Apple UI 開發的未來,但它是一個相當新的事物,還需要花費一些時間來打磨。我們期待改進的文檔,和一個可以爲測試與其他工程化問題建立一套實踐的開發者社區。

需暫緩清單

技術

10x engineers

在過去的幾個月中,10 倍工程師一詞受到了密切關注。一個廣泛傳播的推文甚至建議爲了留住這些產出巨大的工程師,可以無底線地對他們進行包容。幸運的是,許多人在社交媒體上都嘲笑了這個概念,但是“明星開發者”的刻板印象仍然普遍存在。根據我們的經驗,偉大的工程師不是因爲個人產出,而是因爲能在優秀的團隊中合作而誕生。打造一支混合不同經驗和背景,但成員才華橫溢的團隊,併爲團隊合作、學習和持續改進提供良好的助力,這會是更行之有效的方式。這些 10 倍團隊行動起來更快,彈性也更強——而無需屈從錯誤的行爲。

Front-end integration via artifact

當團隊接受微前端這個概念時,他們有很多種方式將各個微前端集成到一個應用程序中,同樣也會有一些微前端的反模式。其中最常見的一種方式就是通過製品進行前端集成。每一個微前端會被構建成一個製品,這個製品通常是一個被推送到註冊表中的 NPM 軟件包。接下來,在不同的構建流水線中,將各個包組合成一個最終的軟件包,這個軟件包包含了所有的微前端。從純粹的技術角度來看,這種集成方式可以使應用程序正常運行。但是,通過製品的方式進行集成,意味着每一次修改都需要重建整個包。這不僅耗時,還有很大可能會帶來負面的開發體驗。更糟糕的是,這種集成方式會引入構建過程中微前端的直接依賴關係,從而導致相當大的協調開銷。

語言 & 框架

Enzyme

我們通常不會將已經移除的工具保留在技術雷達上,但是我們的團隊強烈感受到 Enzyme 應該替換爲 React Testing Library 來用於測試 React 界面組件。使用 Enzyme 的團隊發現它對於被測試組件內部的聚焦會導致脆弱的、無法維護的測試。

如對技術雷達完整版感興趣,可下載 PDF 版報告全文

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章