打造卓越开发者体验的核心原则
我在"开发者体验"领域工作了20多年，通过改进工具、系统和流程来帮助开发者提高效率、效果和幸福感。我曾深入参与Google和LinkedIn开发者体验的关键方面设计，与该领域的研究社区保持密切联系，并经常与各大科技公司的开发者体验负责人交流。
我想为您阐述打造卓越开发者体验的基本原则——在这个领域需要理解的最重要事项。
基本概念
优化开发者体验主要关注三个方面：
周期时间（又称迭代时间）：从开发者产生某个意图到该意图实现之间的时间。
专注度（又称"心流"）：开发者保持专注于当前工作任务而不被打断的能力。
认知负载（又称所需知识和决策）：开发者为了完成任务需要知道多少知识，以及需要做出多少决策。
周期时间（又称迭代时间）
编写软件的过程涉及大大小小的循环，基本上是开发者产生意图到结果在物理世界中实现之间的时间。最小的循环如"我打算写这行代码"，或"我打算运行这个命令行工具并查看输出"。最大的循环如"我打算通过创建产品并让人们使用来解决问题"，或"我们打算以需要100人一年的方式重新设计系统"。
通常，加速大循环的方法是通过加速小循环。如果只专注于加速大循环，结果的质量往往会受到影响。
加速小迭代总是安全的（只要发现它们确实存在问题）。例如，如果代码审查花费太长时间，通常会发现审查者响应不够快。这里的解决方案是专注于审查者响应时间，而不是整体代码审查时间。
这在软件开发的各个部分都适用。如果发现人们编码花费很长时间，值得研究：他们的构建需要多长时间？在开发时本地运行测试需要多长时间？他们能多快获得决策所需的信息？
每个循环都是某种形式的观察、决策、行动循环。如果致力于改进开发者体验，最好的改进方法之一是让开发者更容易观察事物。在他们需要的时候将所需信息放在他们面前。
专注度（又称"心流"）
软件开发是一项需要长时间深度专注才能成功完成的活动。开发者正在构建他们正在处理的事物的非常复杂的心理结构，并使用该心理结构做出决策和编写代码。
当开发者被打断得太彻底或太频繁时，这种复杂的心理结构会消失，必须在返回任务时重新构建。
我们称这种形式的中断为"上下文切换"，此时开发者的注意力主要从编写代码转移到其他事情上。当强迫开发者进行上下文切换时，他们可能需要十到十五分钟才能完全重建专注编码时的心理结构。
中断导致上下文切换的确切时间因人而异。我见过从30秒到2分钟不等的数字。这也取决于中断是什么。
在我的经验中，如果中断引起不良情绪反应，干扰性会更强。
如果想改进心流，思考以下问题：我的工具是否强迫开发者在进行编码、测试或调试时从事一些复杂的非相关任务？我们是否确保开发者有多个不间断的小时来专注于编码？我的工具、系统或流程是否做了让开发者感到非常沮丧以致打断他们专注的事情？
另一个关键点是：开发者是否清楚地知道他们所做工作的目的并有明确的方向？否则，我自己的困惑会经常打断我的专注。
认知负载（又称所需知识和决策）
对于开发者体验，当我们说认知负载时，我们的意思是：开发者为了执行任务需要知道多少？开发者在执行任务时被迫做出多少决策？
减少所需知识
有许多人认为开发者应该尽可能多地了解他们正在做的事情，我同意他们的观点。然而，通过移除他们必须知道才能完成任务的内容，开发者的生产力和体验得到了显著改善。
大多数拥有开发者基础设施的团队在这方面都做得非常糟糕。他们制作的工具要求开发者深入了解该工具才能完成工作。如果开发者不需要与数百个这样的工具交互来完成工作，那还好。
减少选择
这是开发者体验中最具争议的方面之一，但在多家公司的长期经验后，我可以自信地说：开发者应该只需要做出他们需要做出的选择。
有些开发者认为必须允许他们对系统做出每一个选择——用什么编程语言编写，用什么包管理器安装依赖，用什么构建工具，如何缩进代码，用什么监控系统，用什么部署系统等。
走到极端，想象每次开始处理系统更改时，都必须全面研究选择什么编程语言，从10个做同样事情的选项中使用哪个库，使用什么构建工具，与每个人争论制表符与空格，决定使用什么代码审查工具，并通常做出软件工程中涉及的所有其他可能决策。你永远无法完成任何事情，对吧？
在公司内部，我甚至会说开发者不应该被允许做出他们不需要做出的决策。这听起来很极端，但做得好时，实际上会带来出色的开发者体验。
然而，必须非常小心这个原则——开发者需要被允许做出他们需要做出的决策。我观察过很多人编码，每个人使用他们的编辑器及其周围工具的方式都大不相同，因为人们的思维方式大不相同。
必须小心的另一件事是，如果你的基础设施限制了开发者可以做出的决策，你需要非常出色地集中维护该基础设施。
做好的关键是深入了解开发者的需求和他们工作的系统的需求。你需要深入了解他们解决的问题类型，以便知道需要或不需要做出哪些决策。并且你需要能够随时间适当调整这一点（更改策略），而不会开放一切并允许混乱统治。
开发者体验的挑战
开发者体验的大多数困难方面是人的方面，而不是技术方面。其中一些具有技术成分，但大部分困难更多是人类如何做出决策、适应变化等。主要困难包括：
理解问题：现在改进开发者体验最重要的工作是什么？我们如何充分理解这些问题以便构建正确的解决方案？
管理变更：如何推出新变更？如何让人们采用新系统或行为？如何处理对变更感到不安的人？
提供杠杆作用：为开发者构建的工具和系统不应需要太多工作来使用/采用它们，以至于它们实际创造的工作比节省的还多。
说不：你不能一次解决世界上所有问题。你必须能够确定优先级。
将痛苦施加给造成痛苦的人：如果一个团队做了给另一个团队带来困难（“痛苦”）的事情，而制造困难的团队自己从未因此经历任何困难，那么创造的痛苦将无限增长。
理解问题
这里最重要的是要知道问题来自用户，解决方案来自系统开发者。你绝不能颠倒这种关系。
也很容易想：“嘿，我是开发者，所以我知道开发者想要什么”，并完全跳过与用户交谈。这行不通，因为所有开发者的工作方式都非常不同，并且通常有与你非常不同的需求。
反馈和投诉
构建某些东西后，寻找有关系统的数据和反馈非常重要。尽管我们热爱我们构建的东西，但我们应该始终寻找开发者遇到的问题以便解决它们——包括我们刚刚制作的东西的问题！
这里要理解的一点是，在开发者体验领域，人们很少会向你发送正面反馈。当开发者工具"正常工作"时，开发者大多不会考虑它们。然而，如果某些工具或系统使他们难以完成工作，即使只有一点点，他们也会非常清楚这一点。
此外，并非每个开发者都是优秀的反馈提供者。通常，他们只是与某个工具有了非常令人沮丧的体验，他们会向你提供一些非常情绪化的反馈，不会太顾及你的感受。
当你收到非常严厉的反馈时，处理的关键是：让用户知道他们被听到了。如果你的工具存在真正的缺陷，就与用户达成一致！
管理变更
处理改进开发者体验时必须处理的主要因素之一是我们称之为"变更厌恶"的东西。你对系统所做的任何变更在推出时都会收到某些人的负面反馈。发生这种情况不是因为变更实际上有问题，而是因为用户习惯了以前的工作方式，他们不喜欢它发生变化。
重要的是要识别人们的反馈是简单的变更厌恶还是关于有价值事物的真实反馈。有几种方法可以判断：
变更厌恶通常持续3到10天。如果你在推出变更后的前3到10天内收到用户的反馈，并且该反馈不是由大量用户提供的，则值得考虑用户的反应是否只是变更厌恶。
变更厌恶反馈通常是情绪化的。它可能是侮辱性的。它可能表达为意见（“新菜单的颜色很丑”）而不是事实（“我运行了新的命令行工具，它比旧命令行工具慢10倍”）。
增量推出
除了增量开发和设计之外，还必须知道如何增量推出变更，以便并非所有用户同时体验所有变更。这基本上有三个组成部分：
管理发布，使其干扰尽可能小。这意味着小的变更尽最大努力不要求用户做工作来采用变更。
选择良好的初始用户群进行推出，该群组足够大以获得有用的反馈，但不要太大。
了解何时扩展群组以及扩展速度。
推动采用
假设你已经很好地完成了增量推出，但就是无法让人们使用你的新东西。如何解决这个问题？
首先，你必须确保你真正理解了问题，并且该问题是开发者知道并真正希望解决的。然后你必须确保解决方案真正处理了该问题，而不会给开发者带来很多新问题。
只有一个解决方案能让你在整个公司达到100%的采用率：让你工具的使用步骤为零的唯一方法。
这是什么意思？基本上，这意味着将功能直接放入他们的工作流程中，而不是给开发者一些新的手动操作。不是让他们运行工具来检查PR，而是在代码审查期间自动完成。不是让他们运行工具来格式化代码，而是在工作流程的适当点让IDE自动格式化代码。
你绝不应该从让工具使用步骤为零开始。做到正确需要大量工作，在工具生命周期的开始时不值得。
提供杠杆作用
研究工具或改进开发者体验的全部意义在于，你应该为团队/公司节省比投入创建和维护工具更多的精力。
请记住，在软件中，减少维护的工作量比减少创建的工作量更重要。因此，你不仅要考虑工具的直接影响（以及构建它的即时成本），还要考虑它随时间会节省多少精力（以及随时间维护工具的成本是多少）。
人类时间
这个领域最常见的错误之一是通过某种优化节省机器时间（CPU使用、内存使用和磁盘空间的随时间成本），而忘记了你节省了多少人类时间。在大多数情况下，一小时人类时间的成本比所涉及的所有机器时间一小时的成本贵数百倍。
当你考虑开发者生产力改进的成本和价值时，首先考虑你会节省多少人类时间。
服务你的开发者
如果你从事开发者生产力工作，你的口头禅之一应该是"我们为开发者服务，而不是开发者为