开发者体验¹ 是一个² 自说明的术语——开发者的体验——但它难以定义，因为人们在不同时间、出于不同原因、针对不同事物使用这个词。例如，我们自己的 Sarah Drasner 在 Netlify 的职位是“开发者体验副总裁”，所以这是一个非常真实的事物。但职位头衔只是使用这个词的一种方式。让我们深入了解一下，并将它应用于人们思考和使用这个词的不同方式。
人们想到的是 特定技术。
当比较技术时，经常会听到人们使用 DX 这个词。例如，有些人会说 Vue 比 React 提供更好的开发者体验。（我不想引起任何争议，我对此也没有太多意见。）他们指的是 API 之类的东西。也许在一种技术中，状态比另一种技术更直观。或者他们指的是特性。我知道 Vue 和 Svelte 内置了动画助手，而 React 则没有。但是 React 有钩子，人们通常喜欢它们。这些都是这些技术 DX 的方面。
或者他们可能是在谈论围绕核心技术的工具的感受。我知道 create-react-app 很受欢迎，但 Vue CLI 也很受欢迎。 React Router 非常受欢迎，但 Vue 有一个路由器，它得到核心团队的祝福（和维护），这提供了一种信任感。
> vue create hello-world> npx create-react-app my-app我并不是用 JavaScript 框架/库作为随机示例。我听到人们谈论 DX 与 JavaScript 的关系，比其他任何事情都多——这可能是由于我周围的人，但感觉值得注意。
人们想到的是围绕技术的 世界。
每个人都认为好的文档很重要。不存在比另一种技术更好，但文档却差得多的技术。拥有更好文档的技术总体上更好，因为它拥有更好的文档。那不是技术本身，而是围绕技术的世界。
你有没有见过一个开发产品，它有一个 API，当你登录后查看 API 文档时，它使用来自你自己的帐户的 API 密钥、数据和设置来演示？这对我来说非同寻常。这感觉像是 DX。
“让正确的事变得容易，” Jake Dohm 说道。
这个词，“容易”，感觉与 DX 息息相关。使事情变得容易的技术，就是拥有良好 DX 的技术。在使用和理解方面都是如此。我有多容易（以及 多快）能理解你的技术的功能以及我能用它做什么？
技术的功能通常只是故事的一半。顺利执行的路径可能很棒，但如果出现故障或错误怎么办？错误报告和日志记录如何？我在自己的体验中想到了 Apollo 和 GraphQL。这是一项非常棒的技术，但错误报告感觉很糟糕，因为很难跟踪即使是像在开发过程中触发错误的拼写错误之类的错误。
调试故事是什么样的？是否有专门的工具？测试也是如此。这些都是基本的 DX 问题。
人们想到的是技术的 产品和服务。
例如，一项技术可能已经“很好”。假设它有一个开发者喜欢的 API。然后它开始提供 CLI。这通常是 DX 的改进，因为它为更喜欢在该环境中工作以及围绕它构建流程的开发者打开了大门。
我想到了 Netlify Dev。他们已经拥有了这个很棒的平台，然后说，这里，你也可以在自己的机器上运行它。这是认真对待 DX。
netlify dev拥有一个专门的 CLI 几乎总是 DX 的一个好步骤，假设它完成得很好并且维护良好。我记得 WordPress 在 WP-CLI 出现之前，现在很多文档都假设你正在使用它。我甚至不知道 Cloudinary 有一个 CLI，直到有一天我需要它，并且惊喜地发现它在那里。我记得当 npm 脚本开始 接管世界 时。（没有 CLI，npm 会是什么样子？）我们曾经使用过各种不同的任务运行器，但现在基本上假设一个项目具有内置在 package.json 中的运行命令，你可以使用这些命令来完成项目需要做的任何事情。
Melanie Sumner 认为 CLI 属于核心 DX。
人们想到的是 编码 的实际体验。
没有比在代码编辑软件中输入代码并运行它更直接的 DX 了。这就是“编码”的含义，也是开发人员所做的事情。难怪开发人员会认真对待这种体验，并不断尝试为自己和团队改进它。我想到了 VS Code，它在如此短的时间内在代码编辑领域占据主导地位，这主要归功于它的 DX。VS Code 做了很多开发者喜欢的事情，做得很好，做得很快，并且 允许高度定制。
TypeScript 的 流行度不断增长，这无疑部分归功于它在 VS Code 中提供的体验。TypeScript 通过例如显示函数需要的参数，并使错误操作变得困难，来帮助你更好地编码。
然后是在编辑器之外的体验，也就是在浏览器本身中。几年前，我写了 样式注入是赢家的选择，我的观点是，作为一名 CSS 开发人员，保存 CSS 代码并立即在浏览器中看到更改的体验是你绝对想要的 DX。这个概念继续存在，扩展到 JavaScript，其中“热重载” 令人兴奋。
糟糕的开发环境（没有 IDE 帮助，保存速度慢，手动刷新，管道速度慢）和很棒的开发环境（花哨的编辑器辅助，热重载，一切都很快）之间的区别是惊人的。良好的开发环境，良好的 DX，会让你成为一名更好、更高效的程序员。
人们将它与用户体验 (UX) 进行 比较。
DX 有时会带有强烈的负面含义。当人们将其归咎于以牺牲用户体验为代价而存在时，就会发生这种情况。
我想到的是像客户端开发者专用库这样的东西。想想大家最喜欢吐槽的经典库：Moment.js。Moment 允许你在 JavaScript 中操作日期，并且经常用在客户端进行此操作。用户并不关心你是否有一个可以操作日期的漂亮 API。这完全是开发者的便利。因此，你为自己的方便（良好的 DX）发布了这个库，但却导致网站速度变慢（糟糕的 UX）。大多数客户端 JavaScript 属于此类。
同样频繁的是，人们将开发人员体验和用户体验联系在一起。理论认为，如果开发人员被赋予权力并效率高，那么这种好处将“传递下去”，从而产生良好的软件。
最糟糕的情况是，我们处于 UX 和 DX 处于跷跷板上的状态。如果在一边堆积了 DX，那么另一边的 UX 就会受到影响。最好的情况是，我们找到方法完全解开 DX 和 UX，在两者中找到价值，并认真对待两者。尽管如果必须选择一个获胜，那么肯定应该是用户。就像HTML 规范所述
人们考虑时间。
一项技术需要多长时间才能被采用？良好的 DX 会考虑这一点。我是否可以在不重写所有内容的情况下利用它？我需要多长时间才能启动它？它与我使用的其他技术配合得如何？我的时间投入是多少？
这种事情让我想起了最近使用Cloudflare Workers的经验。这是一项非常酷的技术，我们现在没有时间详细介绍，但可以这么说，它赋予你对网站的高级控制权，而我们通常不会想到这一点。例如，如果你可以在网络请求到达你的 Web 服务器之前对其进行操作？你并不一定要使用它，但由于它运行的级别，即使不关心或不干扰你使用的任何技术，也会打开新的大门。
该技术本身不仅定位良好，而且其 DX 虽然有一些粗糙的地方，但也经过深思熟虑，提供了基于浏览器的测试环境。
一个需要高投入成本的强大工具，不错，很酷。但一个需要低投入成本的强大工具才是好的 DX。
人们不想考虑它。
据说最好的排版不会被人注意到，因为你看到的只是文字传达的意思，而不是排版本身。这同样适用于开发人员体验。最好的 DX 就是你永远不会注意到工具或技术，因为它们只是正常工作。
良好的 DX 就是能够完成你的工作，而不是与工具作斗争。这些工具可能是你的开发环境，可能是构建工具，可能是托管内容，甚至可能是你正在使用的 API。API 是直观且有帮助的，还是晦涩难懂且棘手的？
欢迎在评论区继续讨论。对你来说，DX 是什么？
- 我们是否需要将“开发者体验”的首字母大写？我决定就这么写。
- 看起来 Michael Mahemoff 对创造这个词有一定的说法。
我不想把它变成一场语言之争，而且我承认自己有偏见，但在谈论开发者体验时，我认为不应该漏掉 ruby。这种语言的设计理念就是围绕着开发者幸福感。另外，还可以参考Rails 教义，这是一个流行的 ruby 框架。
python 也有一些很棒的理念，但语法太糟糕了，简直是笑话
实际上，我看到 ruby 也好不到哪里去
对我来说，Shopify 的 DX 最糟糕。我仍然对无法缩小 HTML 输出感到震惊，更不用说缺乏对 Git 的支持了。我们能做的最好的事就是使用 Theme Kit 之类的工具，它被宣传为 Shopify 的 GitHub，这让我有点心寒，因为你需要等待从本地代码到远程代码的同步才能看到更改。
我可能错了，如果有任何人知道我说的不对，请告诉我。
人们将它与用户体验进行比较
层次结构没有问题，但还是哪里不对劲..(w3c)
根据我的经验
– 用户通常甚至不知道作者是谁
– 作者通常躲在“我们”、“社区”、“团队”等字眼后面
– 浏览器实现者不听作者的话
– 规范制定者不关心实现者是否听作者的话
因为所有这些
– 应用程序作者首先会听从实现者的意见
所以，你会得到 DX 而不是 UX
我的意思是，层次结构应该得到遵循，并由其成员控制，以创造更美好的世界。
“如果有冲突，请考虑用户优先于作者，作者优先于实现者，实现者优先于规范制定者，规范制定者优先于理论纯度。换句话说，对用户的成本或困难应该比对作者的成本更重要；对作者的成本应该比对实现者的成本更重要”
这应该适用于所有旨在成为好产品的产品
用户养活了你，让他们开心！
不错的文章！确实，我们开发者经常将自己的“开发者体验”与我们认为的“用户体验”混为一谈。
我认为这是一个沉重的议题，我们开发者还没有能够正确地阐明它。
对于日常的普通经理和公司领导来说，开发者体验是优先事项中的最末位。“为什么，我们给你开很多工资，闭嘴好好编码吧，”他们说，因为没有硬性数据，也没有深入的思考，说明为什么一家公司应该投资于此。
但开发者体验也是生产力，生产力通常意味着真金白银。
另一个影响是某些技术的适应性。例如，我从未成功地安装 Java 并启动 Java 代码库，而没有大量搜索错误信息。就我个人而言，我永远不会选择它用于自己的项目。相比之下，安装 node 并运行
create-react-app就容易多了…所以，下一场革命就是认真对待 DX。它将成就或毁灭语言、平台和基础设施。
FWIW，我认为真正好的 DX 总是会考虑到最终用户。如果开发者体验中的某些内容会导致糟糕的性能或导致 UI 无法访问，那么无论开发者的体验多么“好”，这都是糟糕的体验。好的 DX 应该使“正确的事情”成为默认选项或非常容易，并使“错误的事情”难以或不可能实现，我认为我们开发者应该接受这一点。