前端技术雷达最新动向：微前端可采纳，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 版报告全文。