构建卓越开发者体验的核心原则与实践
作者：Max Kanat-Alexander（由qife翻译）
我在"开发者体验"领域工作超过20年，致力于通过改进工具、系统和流程来帮助开发者更高效、更快乐地工作。我深度参与了Google和LinkedIn开发者体验关键方面的设计，与该领域的研究社区保持密切联系，并经常与各大科技公司的开发者体验领导者交流。
我想为您阐述构建卓越开发者体验的基本原则——这个领域中最需要理解的重要内容。我将概述每个要点，可能会遗漏一些内容（因为涉及的内容很多），但希望这能提供一个关于关键点的良好概述。
基本概念
优化开发者体验主要关注三个核心要素：
循环时间（又称迭代时间）：从开发者产生意图到实现该意图所需的时间。
专注度（又称"心流"）：开发者保持专注于当前任务而不被中断的能力。
认知负荷（又称所需知识和决策）：开发者完成任务需要了解多少知识，以及需要做出多少决策。
让我们更详细地讨论这些要点。
循环时间（又称迭代时间）
编写软件的过程涉及大大小小的循环，基本上是开发者产生意图到结果在物理世界中实现之间的时间。最小的循环如"我打算写这行代码"或"我打算运行这个命令行工具并查看输出"。最大的循环如"我打算通过创建产品并让人们使用来解决问题"，或"我们打算用100人一年的时间重新设计系统"。
通常，加速大循环的方法是通过加速小循环。如果只专注于加速大循环，结果的质量往往会受到影响。例如，如果一个团队需要两周时间才能将任何更改部署到生产环境，如果我直接说"无论如何都要更快部署"，而不说其他任何话，团队可能会以损害最终结果质量和软件可维护性的方式走捷径。
然而，如果我更深入地调查，会发现有些小循环耗时过长。可能是代码审查者需要很长时间才能回复。也许测试运行时间太长，开发者每次进行小更改时都需要等待太长时间。也许部署工具太难用，开发者在使用时遇到困难并避免使用它。
另一方面，加速较小的迭代总是安全的（只要发现它们确实存在问题）。例如，假设代码审查耗时过长。通常在这种情况下会发现审查者响应速度不够快。这里的解决方案是专注于审查者响应时间，而不是整体代码审查时间。例如，经常发现代码作者提交的PR太大，导致审查者需要很长时间审查。
代码审查本质上是一个质量过程，因此希望最终结果是高质量的代码。有时开发者和审查者之间需要来回五轮，开发者提交更改，审查者请求修改，直到最终结果良好。希望这五轮都能发生，但希望每一轮都能快速完成。如果每一轮都快速完成，PR审查时间就会恰到好处，开发者和审查者都对过程感到满意。
这适用于软件开发的各个部分。如果发现人们编码耗时过长，值得调查诸如：构建需要多长时间？在开发过程中本地运行测试需要多长时间？他们获取决策所需信息的速度有多快？
还值得注意的是，每个循环都是某种形式的观察、决策、行动循环，我在其他地方详细写过。如果致力于改进开发者体验，最好的改进方法之一是让开发者更容易观察事物。在他们需要的时候将所需信息直接呈现在他们面前。（永远不要将他们不需要的信息放在他们面前，因为这会增加认知负荷，我们稍后会讨论。）例如，当测试失败时，失败信息应清晰指示问题所在，这样开发者就不必费心去弄清楚如何修复。当他们创建新项目时，明确他们的选项（如使用什么语言、框架、如何命名项目等）以及从哪里开始。只需思考：“我如何让开发者永远不需要思考，只需看一眼就知道下一步该做什么？”
专注度（又称"心流"）
软件开发是一项需要长时间深度专注才能成功完成的活动。开发者正在构建他们正在处理的事物的非常复杂的心理结构，并使用该心理结构做出决策和编写代码。他们不断思考（或在笔记中写下）“哦，完成这件事后别忘了做那件事”。这种专注状态通常被称为"处于心流状态"。
当开发者被彻底或频繁打断时，这种复杂的心理结构就会消失，当他们回到任务时必须重新构建。他们可能会忘记脑海中"接下来做这个"的事情，并因此交付有问题的软件。
我们将这种形式的中断称为"上下文切换"，开发者的注意力现在主要放在编写代码以外的其他事情上。当强制开发者进行上下文切换时，他们可能需要十到十五分钟才能完全重建专注编码时的心理结构。因此，小中断可能代价非常高。
中断导致上下文切换的确切时间因人而异。我看到的数字在30秒到2分钟之间。这也取决于中断是什么。如果中断是一个不需要思考的电话通知，你看30秒然后关闭它，这可能不会打断专注。如果中断是作为警报收到的非常复杂的失败消息，无论阅读需要多长时间，都可能打断专注，因为它需要太多的脑力工作，破坏了开发者关于当前任务的心理结构。
根据我的经验，如果中断引起不良情绪反应，可能会更具破坏性。对某事感到不安会分散注意力，难以保持专注于正在做的工作。你会觉得必须对不安做些什么，或者至少思考它。如果有人给我发送令人不安的消息，或者我的某个工具行为极其令人沮丧，即使中断只有5秒，也可能打断我的专注。
如果致力于开发者体验并希望改善心流，请思考以下问题：我的工具是否强制开发者在进行编码、测试或调试任务时参与某些复杂任务？我们是否确保开发者有多个不受干扰的时间专注于编码？我的工具、系统或流程是否做了让开发者感到非常沮丧的事情，从而打断了他们的专注？
另一个关键点是：开发者是否清楚地知道他们所做工作的目的并有明确的方向？也就是说，我是否被赋予了一个明确的任务，我知道为什么要做这个任务，为谁做，以及预期结果是什么？否则，我自己的困惑会经常打断我的专注。我将不得不不断问同事我应该做什么。我会坐在那里思考我的任务，而不是实际去做。此外，我可能无法构建最好的东西，因为我没有做出良好决策所需的所有数据。
专注是另一个需要将清晰信息直接呈现在人们面前的领域，他们可以使用这些信息进行观察、决策和行动。不要让他们中断工作去寻找现在需要的数据。有时，“我要去学习一些东西"是开发者的整个任务，在这种情况下，只要他们能轻松找到所需信息，让他们搜索信息就不是中断。但如果他们正在编码，只需要知道诸如"这个函数是做什么的"之类的信息，这些信息应尽可能快地在他们的编辑器中直接可用。
认知负荷（又称所需知识和决策）
“认知负荷"是我不喜欢的一个术语，因为它含义不明确。就开发者体验而言，我们的意思是：开发者需要了解多少知识才能完成任务？开发者在执行任务时被迫做出多少决策？
我将分别讨论这些要点。
减少所需知识
许多人认为开发者应该尽可能多地了解他们正在做的事情，我同意他们的观点。然而，通过移除他们必须知道的内容来完成任务，开发者的生产力和体验得到了显著改善。当开发者必须编写1和0来编码时，他们的生产力要低得多。用汇编语言编写比用Java或Python等高级语言编写生产力低得多。理解这些语言如何翻译成汇编语言会让你成为更好的程序员吗？是的。但你是否需要知道这些才能完成每个编程任务？不。
这是公司中拥有开发者基础设施的大多数团队严重失败的领域。他们制作的工具要求开发者深入了解该工具才能完成工作。如果开发者不需要与一百个这样的工具交互来完成工作，那也没问题。当然，有时会有更复杂的任务需要开发者深入并真正了解其中一个工具。但理想情况下，每个工具都应该足够直观，开发者不需要学习太多就能成功使用它。更理想的是，应该重新设计基础设施，这样他们根本不需要使用该工具，除非他们真的需要。
减少选择
这是开发者体验中最具争议的方面之一，但在多家公司长期经验后，我可以自信地说：开发者只需要做出他们需要做出的选择。
一些开发者认为必须允许他们对系统做出所有选择——使用什么编程语言、使用什么包管理器安装依赖项、使用什么构建工具、如何缩进代码、使用什么监控系统、使用什么部署系统等。我理解这一点——我对自己最喜欢什么也有强烈的意见。但大多数时候，这样的决策实际上只是迫使团队做他们不应该做的工作——这些工作会分散他们对试图完成的核心任务的注意力。
极端地说，想象一下每次开始对系统进行更改时，都必须全面研究选择什么编程语言、从10个做同样事情的选项中使用哪个库、使用什么构建工具、与每个人争论制表符与空格、决定使用什么代码审查工具，并通常做出软件工程中涉及的所有其他可能决策。你永远无法完成任何事情，对吧？让开发者真正最有效、最高效和快乐的是只专注于他们需要做的任务，而不必不断做出关于该任务之外无数事物的决策。
在公司内部，我甚至会说开发者不应该被允许做出他们不需要做出的决策。这听起来很极端，但如果做得正确，实际上会带来卓越的开发者体验。
问题是开发者经常认为他们需要就实际上不需要的事情做出决策，但他们要几个月或几年后才能看到后果（或者他们无法理解决策将如何影响更大的业务）。例如，不应该允许开发者选择世界上任何编程语言来完成他们的任务——这会迫使他们围绕该语言开发一堆新库或基础设施，而不是专注于他们实际需要完成的任务。这对业务也有许多其他糟糕的长期后果，当你只是一个真正喜欢特定语言的个体开发者时很难看到。（我再次理解！我是一个编程语言爱好者，有很多强烈的个人偏好。）
然而，必须非常小心这个原则——开发者需要被允许做出他们需要做出的决策。我观察过很多人编码，每个人使用他们的编辑器及其周围工具的方式截然不同，因为人们的思维方式截然不同。不能对人们工作流程的某些部分施加太多硬性约束，因为这会在没有对整个业务带来任何实际好处的情况下显著损害生产力。我从未见过公司说"每个人都必须使用这个编辑器"能带来任何好处。我见过"我们将为一个编辑器提供比另一个更多的支持，但我们仍将所有功能作为命令行工具公开，这样你可以使用任何你想要的"能带来好处。
另一件必须小心的事情是，如果你的基础设施限制了开发者可以做出的决策，你需要非常好在中心维护该基础设施。也就是说，一个中心团队需要做出这些决策并持续对结果负责。如果你说"每个人都必须为他们的Java项目使用这个构建工具”，那么你最好确保该工具实际上对每个人都有效，现在和未来持续如此。有时你需要提供一组有限的选择。例如，如果你只是说"每个人都只能用Java编写一切”，你会发现它不是适合所有事情的语言。
做好这一点的关键是深入了解开发者的需求和他们工作的系统的需求。你需要深入了解他们解决的问题类型，以便知道需要或不需要做出哪些决策。你需要能够随着时间的推移适当调整这一点（更改策略），而不是开放一切并允许混乱统治。
事实是，大多数开发者不想就他们的系统做出所有决策，然后被迫做一堆自定义的低级工作才能开始他们的任务。他们喜欢编程，因为他们可以告诉计算机做某事并让它完成，并且因为他们喜欢解决帮助用户的问题。让他们专注于完成这些需要做的事情，而不是软件工程整个宇宙中所有其他可能的决策或任务。
我在《推理与选择》中写了更多关于这方面的内容，包括讨论这个原则如何使推理系统变得更容易。这是任何软件系统最重要的方面之一：无需运行就能推理其行为的能力，而减少选择的原则有助于实现这一点。
请注意，我上面主要从基础设施级选择的角度讨论了这一点，因为如果你是一个致力于开发者体验的中心团队，这通常最重要，但这个原则广泛适用。在团队内部，你可以说"这些是我们的代码模式，请不要使用其他模式"（只要这不限制必要的选择）。在开发工具时，你可以设置合理的默认值，这样人们就不必就工具允许的每个可能选项做出决策。这个原则可以应用的领域有很多很多。
开发者体验的挑战
开发者体验的大多数困难方面是人的方面，而不是技术方面。其中一些有技术成分，但大部分困难更多是关于人类如何做出决策、适应变化等。主要困难是：
理解问题：现在改进开发者体验最重要的工作是什么？我们如何充分理解这些问题以便构建正确的解决方案？
管理变更：如何推出新变更？如何让人们采用新系统或行为？如何处理对变更感到不安的人？
提供杠杆作用：为开发者构建的工具和系统不应需要太多工作来使用/采用，以至于它们实际创造的工作比节省的还多。
说不：你不能一次性解决世界上所有问题。你必须能够确定优先级。此外，有时你会得到团队的需求，他们真的想要某个工具或功能，但这实际上会损害公司的开发者体验。
将痛苦施加给造成痛苦的人：如果一个团队做了给另一个团队带来困难（“痛苦”）的事情，而制造困难的团队自己从未因此经历任何困难，那么创造的痛苦只会不断增长。
让我们更详细地介绍这些。
理解问题
这里最重要的是问题来自用户，解决方案来自系统开发者。绝不能颠倒这种关系，即用户告诉你构建什么解决方案，你构建它，而开发者坐在一起想象没有人实际告诉你的问题。如果你致力于开发者体验，开发者是"用户"，而你是"开发者"。
这可能非常棘手，因为有时你的用户包括高级执行官或技术主管，他们对 exactly 希望你构建什么有强烈意见。你仍然需要坚持立场，只是从他们那里获取问题，同时根据从所有不同用户那里收集的良好数据设计解决方案。奇怪的是（我见过这么多次），如果你构建 exactly 用户告诉你的解决方案，而不是进行良好的研究然后设计最佳解决方案，你的用户不会喜欢它。他们可能一开始喜欢，但随着时间的推移他们会讨厌它，或者为你"设计"它的高管离开，新来的不喜欢它。
也很容易想"嘿，我是开发者，所以我知道开发者想要什么"，完全跳过与用户交谈。这行不通，因为开发者的工作方式都非常不同，通常与你有非常不同的需求。例如，如果你从未与机器学习工程师交谈过，你会震惊地发现这种体验与前端Web开发者的体验有多么不同。
如果你想了解如何从开发者那里收集数据和反馈，我在LinkedIn开发者生产力和幸福框架上做了大量工作，提供了一些如何做到这一点的指南。然而，如果你在小公司工作，你也可以直接与人交谈。这很容易。
反馈和投诉
构建某些东西后，寻求关于系统的数据和反馈非常重要。尽管我们喜欢我们构建的东西，但我们应该始终寻找开发者遇到的问题以便解决它们——包括我们刚刚制作的东西的问题！这最终会随着时间的推移为公司创造最佳的开发者体验。
这里需要理解的一点是，在开发者体验领域，人们很少会发送正面反馈。当开发者工具"正常工作"时，开发者大多不会考虑它们。他们专注于正在做的任务，而不是你的工具，这应该是这样。然而，如果某个工具或系统让他们难以完成工作，即使只是一点点，他们也会非常清楚这一点。
此外，并非每个开发者都是很好的反馈提供者。通常，他们只是与工具有过非常令人沮丧的体验，他们会提供一些非常情绪化的反馈，不会太考虑你的感受。当然，人们不应该这样做，如果你要写反馈，我鼓励你意识到你发送给的人是一个有良好意图的聪明人，所以请尊重他们。但有时会发生，你不应该把它当作对你的人身攻击。
当你收到非常严厉的反馈时，处理的关键是：让用户知道他们被听到了。如果你的工具有真正的缺陷，同意用户的观点！你不必侮辱自己或自己的工作，只需诚实地对待你拥有的东西的状态。当你愿意说"是的，我同意这不是一个好的体验"时，用户实际上更尊重你。这并不意味着你必须立即修复它——你的团队设定自己的优先级。只需让人们知道他们被听到了，他们的投诉是有效的，很多噪音就会平息。
有时在你听到并承认痛苦后，人们仍然很刻薄，在这种情况下，你应该直接告诉他们这种行为不可接受，如果他们继续这样做，就与他们的经理交谈。不过，只有少数人会这样行为。永远不要把这作为你对反馈的第一次回应。
管理变更
在美国长大，我在历史课上学到了改变历史的伟大革命：1776年的美国革命、法国革命、苏联革命等等。这些故事听起来像是领导人引发了暴力革命，然后世界几乎一夜之间改变了。然而，当你研究许多这些情况下实际发生的事情时，“暴力的一夜革命"实际上只是重新建立了一个与以前非常相似（或更糟）的政府，真正积极的变化是通过随着时间的推移较慢的演变发生的。
我喜欢用的类比是在海上转动一艘船。在船实际断裂成两半之前，你只能以某种速率转动一艘非常大的船。船越大，这个转动速率越慢。公司或团队很像这样。它越大，安全地从一个方向"转向"另一个方向的速度就越慢。现在，明确一点，我不是说变更必须永远进行。但它们也不会一夜之间通过魔杖一挥发生。
关于如何安全成功地推出变更，有很多需要了解。
变更厌恶
改进开发者体验时必须处理的主要因素之一是我们所谓的"变更厌恶”。你对系统所做的任何变更在推出时都会收到某人的负面反馈。发生这种情况不是因为变更实际上有问题，而是因为用户习惯了以前的工作方式，他们不喜欢它改变了。他们可能会批评新的用户界面，或者有一些关于新东西为什么"糟糕"的情绪化论点，但通常他们真的只是对任何变更发生感到不安。这不是什么不寻常的事情；这是几乎所有人中都存在的因素。人们往往对在一段时间内愿意经历多少变更有一定的胃口，如果你超出了这个范围，他们会感到不安。
重要的是要识别人们的反馈是简单的变更厌恶还是关于有价值事物的真实反馈。有几种方法可以判断：
变更厌恶通常持续3到10天。如果你在推出变更后的前3到10天内从用户那里收到反馈，并且没有大量用户提供相同的反馈，值得考虑用户的响应是否只是变更厌恶。
变更厌恶反馈通常是情绪化的。可能是侮辱性的。可能表达为只是意见（“新菜单的颜色很丑”）而不是事实（“我运行了新的命令行工具，它比旧命令行工具慢10倍”）。
管理变更时要避免的是创造如此多的变更厌恶以至于引起反抗。反抗基本上看起来像是如此多的人生气以至于去找你的管理层并停止你的工作。如有疑问，向更少的人推出更小的变更，扩展速度更慢。随着时间的推移，你将了解可以推出多少变更，多快推出。永远不要进行"大爆炸"发布，让所有用户一次性体验巨大变更。
现在，所有这些 said，永远不要将所有反馈归因于"变更厌恶"。通常人们确实有合法的反馈。如果许多人提供相同的事实反馈，你查看后觉得他们的反馈有道理，认为修复它会改进产品，那很可能不是变更厌恶。此外，说"这只是变更厌恶"并不意味着你应该完全忽略反馈。你至少应该承认它，让人们知道他们被听到了。这确实意味着你不应该与这个人争论或试图与他们讲道理，因为他们正在情绪化反应，你试图用"逻辑"说服他们不会有帮助。如果你认为是变更厌恶，你承认他们，而他们只是继续与你斗争，有时你应该忽略他们并继续做你的工作。如果三天后他们带着更合理的论点回来，那么你知道这不只是变更厌恶，而且他们到那时可能更有帮助。
增量推出
除了增量开发和设计，还必须知道如何增量推出变更，以便不是所有用户一次性体验所有变更。这基本上有三个组成部分：
管理发布，使其尽可能破坏性最小。这意味着小变更尽最大努力不要求用户做工作来采用变更。
选择一个好的初始用户群体推出，该群体足够大以获得有用反馈，但不要太大。
了解何时扩展群体以及扩展速度