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