摘要开发者体验也称 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 之所以备受关注主要受以下四个因素推动开发者就业市场的变化软件开发方式的演进开发者职责边界的扩大对工程方法一致性的需求上升。首先这与招聘和留住人才密切相关。开发者需求依然旺盛优秀开发者成本高、招聘难、留任也难。如果开发者能够找到一份更符合自身需求和偏好的工作他们又为什么要忍受糟糕的工作体验呢其次软件的构建方式已经发生了巨大变化。无论好坏微服务架构几乎已经成为默认选择。这意味着大多数开发者如今都在构建分布式系统而分布式系统天然伴随着复杂性。此外我们构建系统的方式也越来越多地转向“组装”预制组件而不是从零开始编写所有代码。一幅广为流传的技术漫画就生动呈现了这种变化。这种转变无疑让我们能够更快地构建系统但与此同时选择、组装和运行开发工具链的很大一部分责任也落到了工程师个人身上。有海外分析师将其称为“开发者体验差距”。显然当这种情况发展到一定程度后便难以持续“大多数工具链从写下第一行代码到测试、构建、集成、部署再到进入生产环境都是由来自不同供应商的产品和服务拼接而成的。市场实际上是在告诉开发者及其雇主我们可以提供一个系统引导代码从版本控制中的初始状态一路成长为生产环境中的成熟版本。市场告诉他们这个系统可以非常强大、自动化并且越来越智能。但与此同时市场也在告诉他们你们必须自己构建并维护这个系统。”推动 DevEx 普及的第三个变化是“左移”趋势的发展。越来越多的职责被前移到开发阶段落到开发者身上而不再主要由数据库管理员、安全专家、测试人员和运维人员等专业角色承担。这一演进反过来要求我们提供的工具必须围绕开发者而非专业职能团队的使用体验来设计。仅举一个例子有海外研究文章曾讨论 DX 在帮助开发者构建更安全应用方面的作用“如果我们要求开发者承担更多构建安全应用的责任就必须尽可能简化他们的操作流程。我们需要内置安全默认设置的平台和软件。我们需要融入最小权限原则。我们需要的是安全护栏而不是安全闸门。我们需要关注易用性和速度。我们需要减少开发者需要配置的区域。我们需要自动化。我们需要提升开发者体验。”最后当组织希望通过更自主的团队和可独立部署的微服务来加快系统构建速度时保持一定程度的工程方法一致性就变得至关重要。对于需要跨团队协作的组织而言Worktile 这类通用项目协作系统也可以通过任务、项目、文档、目标、日历、甘特图、工时和审批等能力帮助团队在统一协作空间中推进工作减少沟通和管理成本。海外某银行机构的一位高级工程师曾特别强调“通过标准化少量技术选择并持续改进这些工具和抽象我们让工程师能够专注于手头的业务问题而不是底层基础设施。”总结开发者体验是提升工程生产力的基础能力总体来看开发者体验并不只是某一款工具、某一套平台或某一个团队的职责。它贯穿开发者从编码、测试、构建、部署到生产运维的完整工作链路。对于希望提升工程生产力、加快软件交付速度并留住优秀开发者的组织而言DevEx 已经不再是锦上添花而是一项基础能力。