如约而至｜2017年3月期技术雷达正式发布！

技术雷达是什么

技术雷达是由 ThoughtWorks 技术战略委员会（TAB）经由多番正式讨论给出的最新技术趋势报告，它以独特的雷达形式对各类最新技术的成熟度进行评估并给出建议，为从程序员到CIO/CTO的利益相关者提供参考。

它并不是一个客观的行业分析或者报告，也无意成为一份权威的官方文档，它所展现的就是当下技术领域上的一个“快照”，并进行了粗粒度的分类和趋势分析。对技术趋势的认识只是第一步，通过了解一些第一手的实战经验，并结合自己企业的战略目标进行思考，才能真正的帮助技术管理者做出选择。

这个雷达是图形性质的，把各种技术项目归类为技术、工具、平台和语言及框架。如果某个条目可以出现在多个象限，我们选择看起来最合适的象限。我们还进一步将这些技术分为四个环以反映我们目前对其的态度。要了解关于雷达的更多背景，请点击［阅读原文］

本期五大主题

会话式用户界面（CONVERSATIONALUI）和自然语言处理：

人机对话——这种新的应用程序交互方式——伴随着苹果Siri 、微软小娜和谷歌 Allo 这样的工具，像风暴一样席卷了整个IT生态圈。随后这股风暴继续延伸到了家用设备，例如亚马逊的 Echo 和谷歌的 Home 。虽然构建会话式自然语言用户界面会遇到许多新的挑战，但是它所带来的益处是很显著的。亚马逊 Echo 的研发团队故意在该产品上省去了屏幕，从而迫使团队成员重新思考许多人机交互的场景。

智能即服务

最近，一系列被我们称之为“ 智能即服务”（intelligence asa service）的平台已经爆发。这些平台都与各种强大的技术领域密切相关，从语音处理到自然语言识别、图像识别和深度学习。几年前，要想具备这些能力还需要花费很昂贵的资源，但现在已经有开源或者基于 SaaS 平台的解决方案了。这也意味着“云计算之战”逐渐从存储和计算能力向认知能力转变。

开发者体验成为新的差异化竞争优势

越来越多的组织依据所减少的“工程摩擦力”（engineeringfriction）来评估云产品，并将 API 视为产品来精心打磨，且专注于工程生产力来提升团队效率。在 ThoughtWorks ，我们一直执着于高效的工程实践，以及那些能让开发者们轻松工作的工具和平台。我们非常激动地看到业界开始采纳这些想法。

这些关键技术包括：将内部基础设施作为一种产品，令其具有足够的吸引力来与外部产品进行竞争；专注于自助服务系统；理解所开发的 API 的“开发者人机工程学”（developer ergonomics）；对遗留系统进行封装；以及对开发者的“持续用户共情研究”（ongoing empathetic user research）的投入。

平台的崛起

技术雷达的主题来自于审查过程中的观察和交流。在最近一次编辑技术雷达的过程中，我们注意到了进入平台象限的新条目的数量。我们认为这表明了平台在软件开发生态系统中有着更广阔的前景。那些引人注目的硅谷公司向我们展示了构建一个合理的平台如何带来显著的效益。他们成功的一部分原因来自于找到适用于自身的封装和能力水平。从技术雷达所强调的高级功能（如自然语言处理）到基础设施平台（如亚马逊）来看，越来越多的“平台思维”出现在整个技术生态系统中。

当要通过产品化的 API 提供一些精选的功能时，企业开始考虑采用平台的方式。 开发团队在集成和提升开发人员体验方面有了更多的思考。似乎业界终于走上了将“打包、便利和有用”进行合理组合这样一条道路。我们喜欢这样来定义平台：平台应该提供一个自助服务 API，并且使之在团队环境中容易配置和创建——这很好地与“开发者体验”这样一个新兴的主题相呼应。我们期望在不久的将来，平台的定义和功能将得到进一步的完善。

盛行的PYTHON

Python 这门语言总是不断出现在有趣的地方。作为一门易用的通用编程语言， Python 在数学和科学编程领域具有坚实的基础。这使得它一直以来都为草根阶层的学术研究社区所采用。最近，围绕人工智能商品化及其应用的行业趋势，以及 Python 3 的成熟，给 Python 社区注入了新的活力。

这一卷的雷达重点介绍了一些能够促进 Python 人工智能生态圈发展的库，其中包括机器学习领域的 Scikit-learn ，采用智能数据流图的 TensorFlow 、 Keras 和 Airflow ，以及通过自然语言处理实现会话识别应用程序接口的 sp-Cy 。

亮点提前看

平台工程产品团队：采用云计算和 DevOps ,虽然能通过减少团队对集中式运维团队和基础设施的依赖来提高生产力。但与此同时,也制约了那些缺乏能力对完整应用和运维全技术栈进行自主管理的团队。有些组织开始在内部组建平台工程产品团队以迎接这些挑战。这些团队维护着一个内部的应用平台,使交付团队可以通过自助部署和维护应用,缩短了交付时间,同时也降低了技术栈的复杂性。

这里的重点是该团队维护 API驱动的自助服务和支持工具,而交付团队仍然需要对其在该平台上部署的应用负责。当组织考虑组建这样一个团队的时候应当非常小心,避免无意中创建了独立的 DevOps团队,也不要把现有托管及运维设施打上平台的标签。

游戏领域之外的VR应用：虚拟现实的想法已经存在了50多年了,随着计算技术的不断进步,许多想法都已被炒作和探索过。我们相信该领域目前已经达到了临界点。去年,市场上已经发布了价格适宜的、面向消费者的 VR 头戴式设备,再加上现代的图形显卡为这些设备提供了足够的性能以创造身临其境的体验。虽然这些头戴式设备目前主要还是针对视频游戏爱好者,但我们相信,它们在游戏领域之外的 VR 应用上还存在许多的可能性。但是,没有制作视频游戏经验的团队不应低估创建一个好的3D模型和纹理所需要的时间和技能。

LINUX 安全模块(LSM) ：“最小权限原则”鼓励我们限制软件只访问他们需要的资源。然而在通常情况下,Linux进程可以执行其运行的用户可以做的任何操作,包括绑定端口和执行脚本。 LINUX 安全模块(LSM) 框架允许将安全性扩展至内核,例如 Linux 使用该模块来实现 MAC 。 SELinux 和 AppArmor 是最著名的 LSM 兼容实现,它们随 Linux 内核一起发布。

我们建议团队学习使用这些安全框架(这就是为什么我们将其放置在采用),它可以帮助团队评估谁可以访问共享主机上的哪些资源(包括其中的服务)。这种保守的访问管理方法将帮助团队在其SDLC流程中建立更好的安全性。