在技术洪流中看到我们的态度，第21期技术雷达正式发布！

技术雷达是ThoughtWorks每半年发布一期的技术趋势报告，它不仅是一份持续的技术成熟度评估，其产生还源于ThoughtWorks另一个更大宏大的使命—IT革命。我们一直深信，IT行业从定位、价值、实践和技术都会发生巨大的变革。然而任何宏观的变革，都会有一些微小的信号，我们需要持续关注这些微小的改变，这也就是技术雷达的由来。

技术雷达自2010年创办以来，已经走过10年、累计发布21期。它比那些我们能在市面上见到的其他技术行情和预测报告更加具体、更具可操作性，因为它不仅涉及到新技术大趋势，更有细致到类库和工具的推荐和评论，因此更容易落地。

经过半年的追踪与沉淀，ThoughtWorks TAB（ThoughtWorks技术咨询委员会）根据我们在多个行业中的实践案例，为技术者产出了第21期技术雷达，对百余个技术条目进行分析，阐述它们目前的成熟度，并提供了相应的技术选型建议。

本期四大主题

云：多即是少？

在主流云服务提供商提供的核心功能日益趋同的当下，竞争焦点已经转移到他们能够提供的附加服务上，这就鼓励了云服务商以惊人的速度发布新产品。为在竞争中取得优势，很多新服务还在存有瑕疵、功能尚不完整的阶段，就被匆匆推向市场。过分关注速度以及产品扩张，常常导致这些由收购或仓促打造而来的服务缺陷频出，文档质量差，难于实现自动化，以及与服务商自己的其他服务不能完整集成。团队在尝试使用云服务提供商承诺的功能却经常遇到问题的时候，会感到挫败。考虑到在选择云服务提供商时，通常都是由组织高层基于各个不同维度进行决策，我们建议实施团队：不要假设你们的云服务提供商的所有服务都能确保相同的质量，应该对关键功能进行测试。如果你们的产品上市时间能够容纳额外的运维开销，可以考虑替代的开源解决方案，或者使用多云策略。

保护软件供应链

组织应该抵制冗长的人工检测和需要审批的象牙塔治理规则。相反，自动化的依赖保护（依赖漂移适应度函数），安全性（安全策略即代码）和其他治理机制（运行成本纳入架构适应度函数）可以保护软件项目中重要但不紧急的部分。这个关于策略、合规性和治理即代码的主题在我们对话中多次出现。我们看到自动化不断提升的软件开发生态系统的自然演化：与自动测试、持续交付和基础设施即代码的持续集成，以及如今的自动化治理。云成本、依赖管理、架构结构等以往人工流程的自动化呈现出一种自然演进的态势；我们正在学习如何让软件交付中的所有重要方面自动化。

打开机器学习的黑匣子

通过使用模式匹配、反向传播和其他众所周知的技术，机器学习通常貌似能解决人类所无法解决的问题。然而，尽管这些技术功能强大，但许多模型本质上令人费解。这意味着机器学习所计算的结果，无法用逻辑推理来解释。所以，当需要了解决定是如何做出，或存在将偏见、抽样、算法或其他偏差引入模型的风险时，人们就会一筹莫展。现在我们看到，诸如假设分析之类的工具，以及道德偏差测试这样的技术正在涌现出来。这些工具和技术可以帮助我们发现模型的局限性，并预测模型的输出结果。尽管这些在可解释性方面的改进，是朝着正确方向迈出的一步，但理解深度神经网络，仍然是一个遥不可及的目标。因此，在选择机器学习模型时，数据科学家开始将可解释性视为第一要务。

软件开发是一项团队运动

技术雷达诞生之初，我们就提醒不要使用那些会分隔开发团队、阻碍反馈及协作的工具和技术。通常，当新的专业人才参与项目后，为避免陷入“常规”开发的混乱局面，从业者、供应商和工具会要求某一些开发工作必须在隔离的环境中完成。我们反对这种观念，也在不断寻求新的方法使软件开发重回团队协作。在构建诸如软件之类的复杂工程时，反馈是至关重要的。随着项目不断提升对专业人才的需求，我们努力让他们融入常规的团队协作和反馈互动中。我们特别不提倡“10倍工程师”的理念，更喜欢专注于创建和赋能“10倍团队”。我们已经看到这在如何将设计、数据科学和安全融入跨功能团队，并获得成熟的自动化支持方面发挥了作用。下个阶段应致力于引入更多治理方法和合规行为。

象限亮点抢先看

技术

10x engineers（暂缓）

在过去的几个月中，10倍工程师一词受到了密切的关注。一个广泛传播的推文讨论在实质上建议公司应原谅反社会和破坏性的行为，以留住被认为个人产出巨大的工程师。幸运的是，许多人在社交媒体上都嘲笑了这个概念，但是“明星开发者”的刻板印象仍然普遍存在。根据我们的经验，伟大的工程师不是因为个人产出而是因为能在优秀的团队中合作而诞生。打造一支混合不同经验和背景，但成员才华横溢的团队，并为团队合作、学习和持续改进提供良好的助力，这会是更行之有效的方式。这些10倍团队行动起来更快，弹性也更强，——而无需屈从错误的行为。

Zhong Tai（试验）

近年来，中台一直是中国IT界的流行语，但它尚未在西方国家流行起来。中台的核心是提供封装业务模型的方法。它旨在帮助新型的小型企业提供一流的服务，而无需传统企业基础架构的成本，并使现有组织能够以惊人的速度将创新服务推向市场。中台战略最初是由阿里巴巴提出的，并很快被许多中国的互联网公司所采用，因为它们的商业模式是数字原生的，可以复制到新的市场和领域。如今，越来越多的中国公司将中台作为数字化转型的杠杆。

Continuous delivery for machine learning (CD4ML)（试用）

随着基于ML的应用程序的日益普及以及构建它们所涉及的技术复杂性，我们的团队严重依赖于机器学习的持续交付（CD4ML），以安全快速且可持续的方式交付此类应用程序。CD4ML是将CD原理和实践引入ML应用程序的学科。它消除了从训练模型到部署生产环境的长周期。在构建和部署模型的端到端过程中，CD4ML消除了不同团队、数据工程师、数据科学家和ML工程师之间的手动传递。使用CD4ML，我们的团队成功地实现了基于ML的应用程序所有组件的自动化版本管理，测试和部署，包括数据，模型和代码。

Ethical bias testing（评估）

在过去的一年，我们已经看到人们对机器学习尤其是深度神经网络的兴趣正在发生变化。到目前为止，这些模型的卓越功能推动了工具和技术上令人兴奋的发展。虽然目前，人们越来越担心这些模型可能会造成意外伤害。例如，一个模型可以经过训练，通过简单地排除弱势申请人，而做出有利可图的信用决策。幸运的是，我们看到人们对道德偏见测试的兴趣与日俱增，这将有助于发现潜在的有害决策。一些工具，例如lime, AI Fairness 360 或者 What-if，可以帮助我们发现一些训练数据和可视化工具中未被充分代表的群体而导致的不准确性。可视化工具中，Google Facets和Facets Dive可以用来发现大量训练数据中的子组。但是，这是一个正在发展的领域，我们期待随着时间的推移，出现针对道德偏见测试的标准和实践。

平台

Apollo Auto（试验）

正如 Apollo Auto 所展示的那样，曾经只有科技巨头才能独享的自动驾驶技术，现在已经变得不再高深莫测。百度旗下的 Apollo 项目的目标，是成为自动驾驶产业里的安卓操作系统。Apollo 平台拥有诸如感知、模拟、规划以及智能控制相关的一系列组件，能够让汽车公司将他们的自动驾驶系统集成到汽车硬件中。虽然开发者社区刚刚起步，但是许多第三方厂商陆续加入并贡献良多。我们的一个项目就是帮助客户，使用基于 Apollo 的自动驾驶系统，完成自动驾驶执照的考试。Apollo 同时也提供演进式架构的方法，以逐步引入先进功能，让我们能以敏捷和迭代的方式，集成更多的传感器和功能。

GraalVM（评估）

GraalVM 是一种由 Oracle 开发的通用虚拟机，用于运行基于 JVM 的语言，JavaScript，Python，Ruby 和 R 以及 C/C++ 等其他基于 LLVM 的语言编写的应用程序。简单地说，GraalVM 可以用作 JVM 和其他所支持的非 JVM 的语言的高性能虚拟机。但它也允许我们编写多种语言的应用程序，而且对性能影响很小; 它的原生镜像程序（当前仅可作为早期采用者的技术使用）让我们可以提前将 Java 代码编译成独立的可执行文件，从而加快启动速度并减少内存的使用。GraalVM 在 Java 社区引起了巨大的反响，并且许多 Java 框架（包括Micronaut，Quarkus和Helidon）已经在利用它的技术了。

Oculus Quest（评估）

我们在雷达中对 AR / VR（增强现实/虚拟现实）技术关注了很长时间，但其仅仅在特定的平台及外接方案上展现了吸引力。Oculus Quest 打破了这个局面，成为首批面向大众消费市场的无需智能手机绑定或支持的VR一体机之一。该设备为潜在的 VR 应用的大量增长打开了大门，其需求将反过来推动市场朝着更积极创新的方向发展。我们很欣赏该设备为VR普及带来的推动力，迫不及待地想看到即将到来的变化。

ONNX（评估）

目前，围绕神经网络的相关工具和框架的生态系统正在迅速地发展。但是，这些框架和工具之间的互通性也成为一个挑战。在机器学习领域，通常需要在一种工具中快速进行原型设计和训练，然后将其部署到其他工具中进行推理。因为这些工具的内部格式并不兼容，为了使他们兼容，我们需要实现并维护很多麻烦的转换器。开放神经网络交换格式 ONNX 的出现，就是为解决这一问题。在 ONNX 中，表示神经网络的图形由标准规格的操作符和一系列表示训练权重和神经网络模型的格式所组成，这些图形可以在不同的工具间传递。这种一致的格式带来了很多的可能性，其中之一就是 Model Zoo，它是一系列基于 ONNX 格式的预训练模型的集合。

工具

Figma（试验）

交互和视觉设计的一大痛点是缺乏用于协作的工具， Figma 就是为此而生的。它不仅具有与 Sketch 和 Invision 等设计程序相同的功能，而且还支持与其他人实时协作，帮助多人一起探索新的想法。我们的团队发现Figma非常有用，特别是它支持与简化了远程和分布式的设计工作。除了协作功能之外， Figma 还提供了有助于改善 DesignOps 流程的API。

Jib（试验）

构建容器化应用程序可能需要在开发环境和构建代理上进行复杂的配置。如果你要构建 Java 应用程序并使用 Docker，则可以考虑使用 Google 的 Jib。Jib 是同时支持 Maven 和 Gradle 的开源插件。Jib 插件使用构建配置中的信息，将应用程序直接构建为 Docker 镜像，而不需要 Dockerfile 或 Docker 守护程序。Jib 也针对镜像分层进行了优化，可以提升后续构建的速度。

Twistlock（试验）

Twistlock 是提供构建时和运行时安全漏洞检测和预防功能的商业产品，可以保护 VM 、容器调度程序和容器，以及应用程序依赖的各类注册中心和存储库。Twistlock 帮助我们的团队加快了受监管应用程序的开发，这些应用程序的基础设施和架构需要遵循一定的规范，例如支付卡行业（PCI）标准和《健康保险可移植性和责任法案》（HIPAA）。我们的团队很享受 Twistlock 带来的开发人员体验：能够以代码形式管理资源，可以轻松地与其他常见可观察性平台进行集成，以及根据行业共识最佳实践来衡量基础架构的，直接可用的基准测试。我们在例行的运行时扫描过程中，尤其是在有合规性要求的情况下，使用 Twistlock 对云原生应用程序进行扫描。

in-toto（评估）

我们注意到，越来越多的地方，尤其是在受监管的行业，为了确保软件的供应链安全会使用二进制验证。当前主流的做法，或是构建一个定制的二进制验证系统，亦或是依赖于某个云厂商提供的服务。我们高兴地看到出现了开源的 in-toto 项目。In-toto 是一个框架，能够以密码学的方式验证软件制品生产路径上的每个组件和步骤。该项目可以与众多广泛使用的构建工具、容器审计工具和部署工具进行集成。由于软件供应链工具是一个组织的安全设施中至关重要的部分，因此我们非常喜欢 in-toto。作为一个开源项目，它的行为是透明的，并且其自身的完整性和供应链也可以由社区进行验证。至于它是否会赢得足够多的用户和贡献者以在这个领域竞争，我们拭目以待。

语言&框架

Arrow（试验）

Arrow 是适用于 Kotlin 的函数式编程库，是由两个现有流行库( kategory 和 funKTionale )合并而成。虽然 Kotlin 为函数式编程提供了构建模块，但 Arrow 为应用程序开发人员准备了随时可用的高级抽象包。它提供数据类型、类型类、作用(Effects)、Optics 和其他函数式编程模式，并且可以与流行库相集成。我们对于 Arrow 最初的好印象如今已经在生产环境的应用构建中得到了印证。

Flutter（试验）

我们的一些团队使用了 Flutter 并且很喜爱它。作为跨平台框架，它可以帮助我们用 Dart 语言编写原生移动应用。借助 Dart，Flutter 可以编译成平台原生代码并直接和目标平台通讯，从而避免了桥接和上下文切换。Flutter 的热重载（hot-reload）特性亦让人惊叹，它能在编写代码时提供超快的视觉反馈，我们推荐你在项目中尝试使用 Flutter。

Gatsby.js（评估）

Gatsby.js 是一个用于编写 JAMstack 架构风格网络应用的框架。应用的一部分在构建时生成并且以静态站点的形式进行部署。剩余的功能以渐进式网络应用的方式进行实现并运行在浏览器中。这些应用无需服务端代码即可运行。通常来说，渐进式网络应用会通过调用第三方API，或者现成的 SaaS 解决方案实现内容管理等功能。在 Gatsby.js 的例子中，所有的客户端和构建代码都是用 React 编写。框架包含了一些优化来让程序运行得更快。它将代码与数据分离来最大程度地减少加载时间，并且通过在应用内跳转时预先加载资源来提高性能。接口通过 GraphQL 进行调用并且通过一些插件来简化和现有服务的集成。

SwiftUI（评估）

苹果在其新的 SwiftUI 框架上迈出了一大步，该框架用于在 macOS 和 iOS 平台上实现用户界面。我们很高兴 SwiftUI 跨越了 Interface Builder 和 XCode 之间略显混乱的关系，并采用了一致的、声明性的和以代码为中心的方式。现在，你可以在 XCode 11 中并排查看代码和生成的可视化界面，从而获得更好的开发人员体验。SwiftUI 框架还从近年来主导 Web 开发的React.js 的世界中汲取了灵感，它利用视图模型中的不可变值和异步更新机制，构成了统一的反应式编程模型。这为开发人员提供了一个完全原生的替代品，以替代类似 React Native 或Flutter 之类的反应式框架。尽管 SwiftUI 确实代表了Apple UI 开发的未来，但它是一个相当新的事物，还需要花费一些时间来打磨。我们期待改进的文档，和一个可以为测试与其他工程化问题建立一套实践的开发者社区。

以上是我们在最新一卷技术雷达中随机摘取的几个Blip，欲获取整版技术雷达， 请点击这里 。