【翻译】开发者体验是什么，为什么重要？

作为一个老的Java开发者，在我的日常工作效率方面，对我影响最大的工具之一是一个叫做JRebel的东西。2007年推出的JRebel是一个IDE插件，通过供应商ZeroTurnaround所说的 "热补丁 "或 "动态应用重载 "过程，在很大程度上消除了Java EE开发周期中的构建和重新部署阶段。

这可能看起来很奇怪。当时对我来说，一个典型的部署需要15秒左右，这似乎是微不足道的，但这些小的中断有一个复合效应："我只是在等待部署的时候快速检查电子邮件/瞥一眼我的手机/看看天气报告"，我会想。

作为软件工程师，我们的核心工作是为企业提供价值。花费在与系统或工具斗争上的时间，会使我们失去构建产品的创造性过程。开发者体验（DevEx或DX），有时也被称为工程能力或工程生产力，是关于创造一个环境，让开发者可以做他们最好的工作。这个术语可能会引起混淆，部分原因是它既包括平台团队为提高组织中其他开发团队的生产力所做的工作，也包括为开发者建立的工具--无论这些工具是由内部团队建立的还是从供应商那里购买的。

来自Forthright的Kurt Kemple甚至认为 开发者体验是新的开发者关系，他提供的定义是DevEx是 "生态系统中给开发者留下印象的一个事件或事故"。我个人认为这个定义过于宽泛，没有用处，但这篇博文很有意思，值得一读。

然而，最终，DevEx的目标是使建立 "正确的事情 "成为最容易做到的事情。

DX与UX

就像开发者体验和开发者关系之间有相似之处，开发者体验和用户体验之间也有相似之处。优秀的DevEx，就像优秀的UX一样，最好是不要插手，让开发者处于流动状态。正如 Albert Cavalcante所写的：

"当产品的主要用户是开发者时，开发者体验就相当于用户体验。DX关心的是开发者使用产品的体验，它的库、SDK、文档、框架、开源解决方案、通用工具、API等

。 DX和UX有一些共同的原则，但在良好的实践中存在差异；这是因为与普通用户相比，开发者在他们的日常环境中有不同的需求。

简而言之，DX的重要性与UX的重要性是一样的道理。找到好的DX的开发者会更开心，推广更多，使用他们的产品更久"。

在他们2013年的论文中

，

Fabian Fagerholm和Jürgen Münch在DevEx和UX之间做了同样的平行，并且还提出了更广泛的联系：

"新的工作方式，如全球分布式开发或将自我激励的外部开发者融入软件生态系统，需要更好、更全面地了解开发者的感受、感知、动机，以及对他们在各自项目环境中任务的认同。用户体验是一个捕捉人们对产品、系统和服务感受的概念。它从交互设计和可用性等学科发展到一个更丰富的范围，包括感受、动机和满意度。同样地，开发者体验可以被定义为捕捉开发者对其工作环境中的活动的思考和感受的一种手段，其假设是，开发者体验的改善对持续的团队和项目绩效等特征有积极的影响。

Fagerholm和Münch认为DevEx是一个复杂的社会技术系统，需要考虑开发者从第一行代码开始一直到其发布到生产的过程中与计划和生产软件互动的一切。这将包括文档、SDK、版本控制、可观察性--所有对生产力有影响的东西。与云原生的所有方面一样，组织文化也对一个组织为其开发人员提供良好的DevEx的能力有很大的影响，因此，一个成功的DevEx倡议需要与组织的工程文化相匹配--这就是金融时报、 Mozno和Spotify对DevEx所采取的截然不同的方法。

为什么DevEx现在很重要？

有

四个主要因素在发挥作用，告诉我们为什么DevEx现在正变得如此突出：

• 开发人员就业市场
• 软件开发的演变
• 开发人员责任的变化
• 方法的一致性

第一个是关于招聘和保留。由于需求仍然很高，开发人员很昂贵，很难雇用，也很难保留。当开发者可以找到一份更符合他们需求和喜好的工作时，他们为什么还要忍受糟糕的开发者体验呢？

第二，软件构建的性质也发生了完全不同的变化。首先，不管是好是坏，微服务风格的架构已经成为默认的选择，这意味着大多数开发人员正在构建分布式系统，这意味着所有固有的额外复杂性。但此外，我们构建的系统越来越多地通过组装预制组件而不是从头开始编写一切--Randall Munroe的 这幅XKCD漫画相当精彩地表达了这一想法。

这一转变无疑使我们能够更快地构建系统，但选择、组装和运行这些开发工具链的大部分责任已经留给了个别工程师。RedMonk的Stephen O'Grady将此称为 "开发者经验差距

"

，不言而喻，它在一定程度上是不可持续的：

"大多数工具链，从编写第一行代码到测试、构建、集成和部署，一直到生产，都是由不同供应商的产品和服务拼凑而成的。

市场正在告诉开发者和他们的雇主，实际上，市场可以提供一个系统，将代码从最早的版本控制中的稚嫩日子一直到生产中的成熟阶段。它告诉他们，这个系统可以是强大的、自动化的和越来越智能的。

推动DevEx采用的第三个变化是一切向左转移的趋势，将越来越多的责任放在开发者个人身上，而不是DBA、安全人员、测试人员和运营人员等专家。这种演变反过来又要求我们提供与开发人员而非专家所需相匹配的工具。

仅选取其中之一，Rachel Stephens为RedMonk撰写的文章涉及DX在帮助开发人员构建更安全的应用程序方面的作用：

"如果我们要求开发人员越来越多地负责构建安全的应用程序，我们必须让他们尽可能无摩擦地这样做。我们需要平台和软件具有内置的安全默认功能。我们需要嵌入最小权限的原则。我们需要护栏而不是大门。我们需要关注可用性和速度。我们需要减少暴露给开发人员的配置区域。我们需要自动化。

最后，在这样一个环境中，你想拥有更多的自主团队和可独立部署的微服务，以便能够更快地构建系统，在方法上有一定程度的一致性是至关重要的--Monzo银行的高级员工工程师Suhail Patel 特别强调了这一点：

"通过对一小套技术选择进行标准化，并不断改进这些工具和抽象，我们使工程师能够专注于手头的业务问题，而不是底层的基础设施

"