什么是开发者体验（DevEx/DX）？为什么它对工程效率如此重要？

摘要： 开发者体验，也称 DevEx 或 DX，关注的是开发者在使用工具、平台、文档、SDK、API 和工程流程时的整体感受。优秀的开发者体验能够减少工具摩擦，提升工程生产力，帮助团队更快、更稳定地交付业务价值。

开发者体验是什么？

作为一名资深 Java 开发者，对我日常工作效率影响最大的工具之一，是 JRebel。JRebel 于 2007 年推出，是一款 IDE 插件。它通过其供应商所称的“热补丁”或“动态应用重载”机制，大幅简化了 Java EE 开发周期中的构建与重新部署流程。

这听起来或许有些奇怪。当时，我一次典型的部署大约只需要 15 秒，看似微不足道。但这些短暂的等待会不断累积，并产生意想不到的影响。“我正好趁部署的空档快速看一眼邮件、刷一下手机、查一下天气。”我常常这样想。可等回过神来，原本连贯的思路已经被彻底打断了。

作为软件工程师，我们的核心工作是为业务创造价值。如果大量时间都被消耗在与系统或工具的摩擦上，我们用于构建产品的创造力就会被不断分散。开发者体验，即 DevEx 或 DX，有时也被称为工程赋能或工程生产力，关注的正是如何创造一个让开发者能够充分发挥潜能的环境。

这个术语有时会让人困惑，部分原因在于它涵盖的范围很广：一方面，它指平台团队为提升组织内其他开发团队生产力所做的工作；另一方面，它也指面向开发者构建的工具，无论这些工具由内部团队开发，还是从外部供应商处采购而来。比如在研发管理场景中，PingCode 这类智能化研发管理工具，就可以将目标管理、客户反馈、需求清理、评审排期、开发、测试、发布和知识沉淀等环节串联起来，减少流程断点，让研发数据在不同工具之间更顺畅地流转。

有海外从业者甚至提出，开发者体验就是新的开发者关系，并将其定义为“开发者在生态系统中所感知到、并对其留下印象的事件或现象”。我个人认为，这一定义过于宽泛，实用性有限。不过，这类观点颇有启发，仍然值得关注。

归根结底，DevEx 的目标是：让开发者能够以最顺畅的方式，正确地构建真正有价值的东西。

开发者体验 DX 与用户体验 UX 有什么关系？

正如开发者体验与开发者关系之间存在相似之处，开发者体验与用户体验之间也有许多共通点。优秀的开发者体验，就像优秀的用户体验一样，理想状态下应当让开发者专注于手头的工作，而不是被完成工作的过程所干扰。正如一位海外从业者所写：

“开发者体验类似于用户体验，只不过产品的主要用户是开发者。开发者体验关注的是开发者在使用产品及其库、SDK、文档、框架、开源解决方案、通用工具和 API 等内容时的整体感受。”

DX 和 UX 共享一些基本原则，但在最佳实践上又有所不同，因为开发者在日常工作中的需求与普通用户并不完全相同。

简而言之，DX 之所以重要，原因与 UX 之所以重要并无二致：当开发者认为某个产品的开发者体验足够好时，他们会更满意，更愿意推荐该产品，也更可能长期使用它。

两位研究者在 2013 年的一篇论文中，也对 DevEx 和 UX 进行了类似类比，并进一步提出了更广泛的联系：

“全球分布式开发，或将积极主动的外部开发者整合进软件生态系统等新型工作方式，都要求我们更深入、更全面地理解开发者在各自项目环境中的感受、认知、动机，以及他们对任务的认同感。用户体验这一概念，用于描述人们对产品、系统和服务的感受。它由交互设计、可用性等学科发展而来，并进一步涵盖感受、动机和满意度等更丰富的内容。同样，开发者体验也可以被定义为一种理解开发者如何在工作环境中看待和感受自身活动的方式。其基本假设是，改善开发者体验将对团队和项目的持续绩效等方面产生积极影响。”

在这种视角下，DevEx 是一个复杂的社会技术系统。它需要考虑开发者在规划和开发软件过程中接触到的一切，从写下第一行代码，到最终发布到生产环境。这其中包括文档、SDK、版本控制、可观测性，以及所有会影响开发效率和工程生产力的因素。

与云原生技术的许多方面一样，组织文化也会显著影响一家组织能否为开发者提供良好的 DevEx。因此，成功的 DevEx 计划必须与组织自身的工程文化相匹配。这也解释了为什么海外某些媒体机构、银行机构和科技公司会采用截然不同的 DevEx 方法。

DevEx 现在为何如此重要？

如今，DevEx 之所以备受关注，主要受以下四个因素推动：

1. 开发者就业市场的变化；
2. 软件开发方式的演进；
3. 开发者职责边界的扩大；
4. 对工程方法一致性的需求上升。

首先，这与招聘和留住人才密切相关。开发者需求依然旺盛，优秀开发者成本高、招聘难、留任也难。如果开发者能够找到一份更符合自身需求和偏好的工作，他们又为什么要忍受糟糕的工作体验呢？

其次，软件的构建方式已经发生了巨大变化。无论好坏，微服务架构几乎已经成为默认选择。这意味着，大多数开发者如今都在构建分布式系统，而分布式系统天然伴随着复杂性。此外，我们构建系统的方式也越来越多地转向“组装”预制组件，而不是从零开始编写所有代码。一幅广为流传的技术漫画，就生动呈现了这种变化。

这种转变无疑让我们能够更快地构建系统，但与此同时，选择、组装和运行开发工具链的很大一部分责任，也落到了工程师个人身上。有海外分析师将其称为“开发者体验差距”。显然，当这种情况发展到一定程度后，便难以持续：

“大多数工具链，从写下第一行代码，到测试、构建、集成、部署，再到进入生产环境，都是由来自不同供应商的产品和服务拼接而成的。

市场实际上是在告诉开发者及其雇主：我们可以提供一个系统，引导代码从版本控制中的初始状态，一路成长为生产环境中的成熟版本。市场告诉他们，这个系统可以非常强大、自动化，并且越来越智能。但与此同时，市场也在告诉他们：你们必须自己构建并维护这个系统。”

推动 DevEx 普及的第三个变化，是“左移”趋势的发展。越来越多的职责被前移到开发阶段，落到开发者身上，而不再主要由数据库管理员、安全专家、测试人员和运维人员等专业角色承担。这一演进反过来要求我们提供的工具，必须围绕开发者而非专业职能团队的使用体验来设计。

仅举一个例子，有海外研究文章曾讨论 DX 在帮助开发者构建更安全应用方面的作用：

“如果我们要求开发者承担更多构建安全应用的责任，就必须尽可能简化他们的操作流程。我们需要内置安全默认设置的平台和软件。我们需要融入最小权限原则。我们需要的是安全护栏，而不是安全闸门。我们需要关注易用性和速度。我们需要减少开发者需要配置的区域。我们需要自动化。我们需要提升开发者体验。”

最后，当组织希望通过更自主的团队和可独立部署的微服务来加快系统构建速度时，保持一定程度的工程方法一致性就变得至关重要。对于需要跨团队协作的组织而言，Worktile 这类通用项目协作系统，也可以通过任务、项目、文档、目标、日历、甘特图、工时和审批等能力，帮助团队在统一协作空间中推进工作，减少沟通和管理成本。海外某银行机构的一位高级工程师曾特别强调：

“通过标准化少量技术选择，并持续改进这些工具和抽象，我们让工程师能够专注于手头的业务问题，而不是底层基础设施。”

总结：开发者体验是提升工程生产力的基础能力

总体来看，开发者体验并不只是某一款工具、某一套平台，或某一个团队的职责。它贯穿开发者从编码、测试、构建、部署到生产运维的完整工作链路。对于希望提升工程生产力、加快软件交付速度并留住优秀开发者的组织而言，DevEx 已经不再是锦上添花，而是一项基础能力。