什么是卓越的开发者体验？

我在"开发者体验"领域工作了20多年，我们通过改进工具、系统和流程来帮助开发者更高效、更快乐。我深度参与了Google和LinkedIn的开发者体验关键设计，与该领域的研究社区保持密切联系，并经常与各大科技公司的开发者体验领导者交流。

我想为你阐述打造卓越开发者体验的基本原则——这个领域最重要的理解要点。我将概述每个要点，可能会遗漏一些内容（因为涉及的内容很多），但希望这是对关键点的良好概述。

基本概念

优化开发者体验主要关注三个核心要素：

周期时间（又称迭代时间）：从开发者产生意图到实现该意图所需的时间。

专注度（又称"心流"）：开发者保持专注于当前任务而不被打断的能力。

认知负荷（又称所需知识和决策）：开发者完成任务需要知道多少知识，以及需要做出多少决策。

让我们更详细地讨论这些要点。

周期时间（又称迭代时间）

编写软件的过程涉及大大小小的循环，基本上是开发者产生意图到结果在物理世界中实现之间的时间。最小的循环如"我打算写这行代码"或"我打算运行这个命令行工具并查看输出"。最大的循环如"我打算通过创建产品并让人们使用来解决问题"，或"我们打算用100人一年的时间重新设计系统"。

通常，加速大循环的方法是通过加速小循环。如果只专注于加速大循环，结果质量往往会受到影响。例如，如果一个团队需要两周时间才能将任何更改部署到生产环境，如果我直接说"无论如何都要更快部署"，而不说其他话，团队可能会走捷径，从而损害最终结果的质量和软件的可维护性。

然而，如果我更深入地调查，会发现有些小循环耗时过长。可能是代码审查者需要很长时间才能回复。也许测试运行时间太长，开发者每次做小改动都要等待太久。或者部署工具太难用，开发者在使用时遇到困难并避免使用。

另一方面，加速小迭代总是安全的（只要你发现它们确实存在问题）。例如，如果代码审查耗时过长，通常会发现审查者响应不够快。这里的解决方案是专注于审查者响应时间，而不是整体代码审查时间。通常会发现代码作者提交的PR太大，导致审查者需要很长时间审查。

代码审查本质上是质量过程，你希望最终结果是高质量的代码。有时开发者和审查者之间需要五轮来回，开发者提交更改，审查者要求修改，直到最终结果良好。你希望这五轮都发生，但希望每轮都快速完成。如果每轮都快速完成，PR审查时间就会恰到好处，开发者和审查者都对过程满意。

这在软件开发的各个部分都适用。如果发现编码耗时很长，值得调查：构建需要多长时间？开发时本地运行测试需要多长时间？他们能多快获得决策所需的信息？

值得注意的是，每个循环都是某种形式的观察、决策、行动循环，我在其他地方详细写过。如果致力于改进开发者体验，最好的改进方法之一是让开发者更容易观察事物。在他们需要的时候将所需信息直接呈现在面前。（永远不要将他们不需要的信息放在面前，因为这会增加认知负荷，我们稍后会讨论。）例如，测试失败时，失败信息应清晰指出问题所在，这样开发者就不必费力去弄清楚如何修复。创建新项目时，明确他们的选项（如使用什么语言、框架、如何命名项目等）以及从哪里开始。只需思考：“我如何让开发者永远不需要思考，只需看一眼就知道下一步该做什么？”

专注度（又称"心流"）

软件开发是一项需要长时间深度专注才能成功完成的活动。开发者正在构建他们正在处理的事物的非常复杂的心理结构，并使用该心理结构做出决策和编写代码。他们不断思考（或在笔记中写下）“哦，完成这件事后别忘了做那件事”。这种专注状态通常被称为"心流"。

当开发者被彻底或频繁打断时，这种复杂的心理结构就会消失，当他们回到任务时必须重新构建。他们可能会忘记脑海中"接下来做这个"的事情，并因此发布有问题的软件。

我们将这种形式的中断称为"上下文切换"，开发者的注意力现在主要放在编写代码之外的事情上。当你强制开发者进行上下文切换时，他们可能需要十到十五分钟才能完全重建专注编码时的心理结构。因此，小中断可能代价很高。

中断导致上下文切换的确切时间因人而异。我见过的数字在30秒到2分钟之间。这也取决于中断是什么。如果中断是不需要思考的电话通知，你看30秒就 dismiss，可能不会打断专注。如果中断是作为警报收到的非常复杂的失败消息，无论阅读需要多长时间，都可能打断专注，因为它需要大量脑力工作，破坏了开发者对当前任务的心理结构。

根据我的经验，如果中断引起不良情绪反应，干扰性更强。对某事感到不安会分散注意力，难以继续专注于正在做的工作。你觉得必须对不安做点什么，或者至少思考它。如果有人给我发送令人不安的消息，或者我的某个工具行为极其令人沮丧，即使中断只有5秒，也可能打断我的专注。

如果你致力于开发者体验并希望改善心流，请思考：我的工具是否强制开发者在进行编码、测试或调试时从事一些复杂的非相关任务？我们是否确保开发者有多个不受干扰的小时专注于编码？我的工具、系统或流程是否做了让开发者非常沮丧以至于打断他们专注的事情？

另一个关键点是：开发者是否清楚地知道他们所做工作的目的并有明确的方向？也就是说，我是否被赋予了明确的任务，知道为什么要做这个任务，为谁做，以及预期结果是什么？否则，我自己的困惑会经常打断我的专注。我必须不断问同事我应该做什么。我会坐在那里思考我的任务，而不是实际去做。此外，我可能无法构建最好的东西，因为我没有做出良好决策所需的所有数据。

专注是另一个领域，你希望将清晰的信息直接呈现在人们面前，供他们观察、决策和行动。不要让他们中断工作去寻找现在需要的数据。有时，“我要去学习一些东西"是开发者的整个任务，在这种情况下，只要他们能轻松找到所需信息，让他们搜索信息就不是中断。但如果他们正在编码，只需要知道"这个函数是做什么的”，这些信息应尽可能快地在编辑器中直接可用。

认知负荷（又称所需知识和决策）

“认知负荷"是我不喜欢的术语，因为它含义不明确。对于开发者体验，我们的意思是：开发者需要知道多少才能完成任务？开发者在执行任务时被迫做出多少决策？

我将分别讨论这些要点。

减少所需知识

许多人认为开发者应该尽可能多地了解他们在做什么，我同意。然而，通过移除完成任务必须知道的东西，开发者的生产力和体验会显著提高。当开发者必须用1和0编码时，生产力远不如用Java或Python等高级语言编写。理解这些语言如何翻译成汇编语言能让你成为更好的程序员吗？是的。但你是否需要知道这些才能完成每个编程任务？不需要。

这是公司中拥有开发者基础设施的大多数团队严重失败的领域。他们制作的工具要求开发者深入了解该工具才能完成工作。如果开发者不需要与一百个这样的工具交互来完成工作，那也没问题。当然，有时会有更复杂的任务需要开发者深入并真正学习其中一个工具。但理想情况下，每个工具应该足够直观，开发者不需要学习太多就能成功使用。更理想的是，应该重新设计基础设施，这样除非真正需要，否则他们根本不需要使用该工具。

减少选择

这是开发者体验中最具争议的方面之一，但在多家公司长期经验后，我可以自信地说：开发者只需要做出他们需要做出的选择。

一些开发者认为必须允许他们对系统做出所有选择——使用什么编程语言、使用什么包管理器安装依赖、使用什么构建工具、如何缩进代码、使用什么监控系统、使用什么部署系统等。我理解——我对自己最喜欢什么也有强烈意见。但大多数时候，这样的决策实际上只是强迫团队做不应该做的工作——分散他们完成核心任务注意力的工作。

极端地说，想象每次开始对系统进行更改时，都必须全面研究选择什么编程语言、从10个做同样事情的库中选择哪个库、使用什么构建工具、与每个人争论制表符与空格、决定使用什么代码审查工具，并基本上做出软件工程中涉及的所有其他可能决策。你永远完成不了任何事情，对吧？让开发者最有效、最高效和最快乐的是专注于他们需要完成的任务，而不是不断做出无数外部决策。

在公司内部，我甚至会说开发者不应该被允许做出他们不需要做出的决策。这听起来很极端，但如果做得正确，实际上会带来卓越的开发者体验。

问题是开发者经常认为他们需要对自己实际上不需要的事情做出决策，但几个月或几年后才会看到后果（或者他们无法理解决策如何影响更大的业务）。例如，不应该允许开发者选择世界上任何编程语言来完成他们的任务——这迫使他们围绕该语言开发一堆新库或基础设施，而不是专注于他们需要实际完成的任务。这对业务也有许多其他不良长期后果，当你只是一个真正喜欢特定语言的个体开发者时很难看到。（我再次理解！我是一个编程语言极客，有很多强烈的个人偏好。）

然而，必须非常小心这个原则——开发者需要被允许做出他们需要做出的决策。我观察过很多人编码，每个人使用编辑器及其周围工具的方式截然不同，因为人们的思维方式截然不同。你不能对人们工作流的某些部分施加太多硬性约束，因为这会显著损害生产力，而对整个业务没有任何实际好处。我从未见过公司说"每个人都必须使用这个编辑器"能带来什么好处。我见过"我们将为一个编辑器提供比另一个更多的支持，但仍将所有功能作为命令行工具公开，这样你可以使用任何你想要的"能带来好处。

另一件必须小心的事情是，如果你的基础设施限制了开发者可以做出的决策，你需要非常好在中心维护该基础设施。也就是说，一个中心团队需要做出这些决策，并持续对结果负责。如果你说"每个人都必须为他们的Java项目使用这个构建工具”，那么你最好确保该工具实际上对每个人都有效，现在和未来持续如此。有时你需要提供一组有限的选项。例如，如果你只说"每个人都只能用Java编写一切"，你会发现它不是适合所有事情的语言。

做好的关键是深入了解开发者的需求和他们工作的系统需求。你需要深入了解他们解决的问题类型，以便知道需要或不需要做出什么决策。你需要能够随时间适当调整（更改策略），而不是开放一切并允许混乱统治。

事实是，大多数开发者不想对系统做出所有决策，然后被迫做一堆自定义低级工作才能开始任务。他们喜欢编程，因为他们可以告诉计算机做某事并让它执行，并且他们喜欢解决帮助用户的问题。让他们专注于完成这些需要做的事情，而不是软件工程整个宇宙中所有其他可能的决策或任务。

我在《推理与选择》中写了更多关于这方面的内容，包括讨论这个原则如何使推理系统变得更容易。这是任何软件系统最重要的方面之一：无需运行就能推理其行为的能力，减少选择的原则有助于实现这一点。

注意，我上面主要讨论基础设施级选择，因为如果你是一个致力于开发者体验的中心团队，这通常最重要，但这个原则广泛适用。在团队内部，你可以说"这些是我们的代码模式，请不要使用其他模式"（只要不限制必要的选择）。开发工具时，你可以设置合理的默认值，这样人们就不必对工具允许的每个可能选项做出决策。这个原则可以应用的领域非常多。

开发者体验的挑战

开发者体验的大多数困难方面是人的方面，而不是技术方面。其中一些有技术成分，但大部分困难更多是人类如何做出决策、适应变化等。主要困难是：

理解问题：现在改进开发者体验最重要的工作是什么？我们如何充分理解这些问题以便构建正确的解决方案？

管理变更：如何推出新变更？如何让人们采用新系统或行为？如何处理对变更感到不安的人？

提供杠杆作用：为开发者构建的工具和系统不应需要太多工作来使用/采用，以至于它们实际创造的工作比节省的还多。

说不：你不能一次性解决世界上所有问题。你必须能够确定优先级。此外，有时你会得到团队的需求，他们真正想要某个工具或功能，但这实际上会损害公司的开发者体验。

将痛苦施加给造成痛苦的人：如果一个团队做了给另一个团队带来困难（“痛苦”）的事情，而制造痛苦的团队自己从未感受到任何困难，那么创造的痛苦将无限增长。

让我们更详细地介绍这些。

理解问题

这里最重要的是问题来自用户，解决方案来自系统开发者。你绝不能、绝不能颠倒这种关系，即用户告诉你构建什么解决方案，你构建它，而开发者坐在一起想象没有人实际告诉你的问题。如果你致力于开发者体验，开发者是"用户"，而你是"开发者"。

这可能非常棘手，因为有时你的用户包括高级执行官或技术主管，他们对要你构建什么有强烈意见。你仍然需要坚持立场，只是从他们那里获取问题，同时根据从所有不同用户收集的良好数据设计解决方案。奇怪的是（我见过很多次），如果你完全按照用户告诉你的构建解决方案，而不是做好研究然后设计最佳解决方案，你的用户不会喜欢它。他们可能一开始喜欢，但随着时间的推移会变得讨厌，或者为你"设计"的高管离开，新来的不喜欢。

也很容易想，“嘿，我是开发者，所以我知道开发者想要什么”，完全跳过与用户交谈。这行不通，因为开发者的工作方式非常不同，通常有与你非常不同的需求。例如，如果你从未与机器学习工程师交谈过，你会震惊地发现这种体验与前端Web开发者的体验有多么不同。

如果你想了解如何从开发者那里收集数据和反馈，我在LinkedIn开发者生产力和幸福框架上做了大量工作，提供了一些如何做的指南。然而，如果你在小公司工作，也可以直接与人交谈。这很容易。

反馈和投诉

构建某些东西后，寻求有关系统的数据和反馈非常重要。尽管我们热爱我们构建的东西，但我们应该始终寻找开发者的问题以便解决——包括我们刚做的东西的问题！这最终会随时间为公司创造最佳开发者体验。

这里要理解的一点是，在开发者体验领域，人们很少会发送正面反馈。当开发者工具"正常工作"时，开发者大多不会考虑它们。他们专注于正在做的任务，而不是你的工具，这应该是这样。然而，如果某个工具或系统让他们难以完成工作，即使只是一点点，他们也会非常清楚。

此外，不是每个开发者都是很好的反馈提供者。通常，他们刚刚与工具有过非常令人沮丧的经历，他们会提供一些非常情绪化的反馈，不会很考虑你的感受。当然，人们不应该这样做，如果你要写反馈，我鼓励你意识到你发送的人是一个有良好意图的聪明人，所以请尊重他们。但有时会发生，你不应该把它当作对你的人身攻击。

当你收到非常严厉的反馈时，处理的关键是：让用户知道他们被听到了。如果你的工具有真正的缺陷，同意用户的观点！你不必侮辱自己或自己的工作，只需诚实地对待你拥有的东西的状态。当你愿意说"是的，我同意这不是一个好的体验"时，用户实际上更尊重你。这并不意味着你必须立即修复——你的团队设定自己的优先级。只需让人们知道他们被听到了，他们的投诉是有效的，很多噪音就会平息。

有时在你听到并承认痛苦后，人们仍然很刻薄，在这种情况下，你应该直接告诉他们这种行为不可接受，如果他们继续这样做，就与他们的经理交谈。不过，只有少数人会这样行为。永远不要把这作为你对反馈的第一反应。

管理变更

在美国长大时，我在历史课上学到了改变历史的伟大革命：1776年美国革命、法国革命、苏联革命等。故事听起来像是领导人引发了暴力革命，然后世界几乎一夜之间改变。然而，当你研究许多这些情况下实际发生的事情时，“暴力的一夜革命"实际上只是重建了一个与之前非常相似的政府（或更糟），真正积极的变化是通过随时间较慢的进化发生的。

我喜欢用的类比是在海上转动一艘船。在船实际断裂成两半之前，你只能以某种速率转动一艘非常大的船。船越大，转动速率越慢。公司或团队很像这样。规模越大，安全地从一個方向"转向"另一个方向的速度越慢。现在，明确地说，我不是说变更必须永远进行。但它们也不会一夜之间通过魔杖一挥发生。

关于如何安全成功地推出变更，有很多需要了解。

变更厌恶

改进开发者体验时必须处理的主要因素之一是我们所谓的"变更厌恶”。你对系统做的任何变更在推出时都会收到某人的负面反馈。发生这种情况不是因为变更实际上有问题，而是因为用户习惯了以前的工作方式，他们不喜欢它改变了。他们可能会批评新的用户界面，或者有一些关于新东西为什么"糟糕"的情绪化论点，但通常他们真的只是对任何变更发生感到不安。这并不罕见；它存在于几乎所有人中。人们往往对在一定时间内愿意经历多少变更有一定的承受能力，如果你超出那个范围，他们会感到不安。

重要的是要识别人们的反馈是简单的变更厌恶还是关于有价值事物的真实反馈。有几种方法可以判断：

变更厌恶通常持续3到10天。如果你在推出变更后的前3到10天内从用户那里收到反馈，并且没有大量用户提供相同的反馈，值得考虑用户的反应是否只是变更厌恶。

变更厌恶反馈通常是情绪化的。可能是侮辱性的。可能表达为只是意见（“新菜单的颜色很丑”） vs 事实（“我运行了新的命令行工具，它比旧的命令行工具慢10倍”）。

管理变更时要避免的是创造如此多的变更厌恶以至于引起反抗。反抗基本上看起来像如此多的人生气，他们去找你的管理层并停止你的工作。如有疑问，向更少的人推出更小的变更，扩展速度更慢。随时间推移，你将了解可以推出多少变更，多快推出。永远、永远不要做"大爆炸"发布，让所有用户一次性经历巨大变更。

现在，所有这些 said，永远不要将所有反馈归因于"变更厌恶"。通常人们确实有合法的反馈。如果许多人提供相同的事实反馈，你查看后觉得他们的反馈有道理，认为修复会改进产品，那很可能不是变更厌恶。此外，说"这只是变更厌恶"并不意味着你应该完全忽略反馈。你至少应该承认，让人们知道他们被听到了。这确实意味着你不应该与那个人争论或试图与他们讲道理，因为他们有情绪反应，你试图用"逻辑"说服他们不会帮助任何人。如果你认为是变更厌恶，你承认他们，他们只是继续与你斗争，有时你应该忽略他们，继续做你的工作。如果他们3天后带着更合理的论点回来，那么你知道不只是变更厌恶，而且他们到那时可能更有帮助。

增量推出

除了增量开发和设计，还必须知道如何增量推出变更，以便不是所有用户一次性经历所有变更。这基本上有三个组成部分：

管理发布，使其尽可能破坏性最小。这意味着小变更，尽力不要求用户做工作来采用变更。

选择良好的初始用户群推出，足够大以获得有用反馈，但不要太大。

了解何时扩展群组以及扩展速度多快。

最小破坏意味着：不要破坏用户的系统。不要求用户做手动工作来采用变更。必要时提供清晰文档。确保系统提供非常清晰的错误消息，以便开发者在首次尝试失败时知道该做什么。基本上，设身处地为用户着想，思考"我有很多事情要做，我每天使用30个工具来做。当有新功能或新工具供我使用时，我想要有什么体验？"

选择初始群组主要是关于谁将提供有用反馈，以及需要组中有多少人才能获得该反馈。开发时，通常你和你的团队就足够了。然后可能是你的技术主管、组织中的一些高级人员，以及你领域外真正想采用