什么造就了卓越的开发者体验？

我在“开发者体验”领域工作了超过20年，我们通过改进工具、系统和流程来帮助开发者更有效、高效和快乐。我深度参与了Google和LinkedIn开发者体验的关键方面设计，与该领域的研究社区密切合作，并不断与各大科技公司的开发者体验领导者交流。

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

基本概念

优化开发者体验主要有三个目标：

• 周期时间（又称迭代时间）：从开发者有任何意图到该意图完成的时间。
• 专注度（又称“心流”）：开发者保持专注于他们正在工作的任务，不被中断的能力。
• 认知负荷（又称所需知识和决策）：开发者为了完成他们正在做的任务必须知道多少，以及他们必须做出多少决策来完成他们的任务。

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

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

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

通常，加速大循环的方式是加速小循环。如果你只专注于加速大循环，结果的质量往往会受到影响。例如，假设我看到一个团队需要两周时间才能将任何更改部署到生产环境。如果我只是进去说“无论如何都要更快部署”，而不说其他任何话，那么团队可能会以损害最终结果质量和软件可维护性的方式偷工减料。

然而，如果我更深入地调查，我会发现有一些小循环花费了太长时间。也许代码审查者需要永远才能回应。可能测试运行时间太长，因此开发者每次进行小更改时都必须等待太长时间。可能部署工具太难使用，因此开发者与之斗争并避免使用它。

另一方面，加速较小的迭代总是安全的（只要你发现它们确实有问题）。例如，假设代码审查花费了太长时间。通常，在这种情况下你会发现审查者只是回应不够快。这里的解决方案是专注于审查者响应时间，而不是整体代码审查时间。例如，你经常发现在这种情况下，代码作者发送的PR太大，因此审查者需要永远才能审查它们。

代码审查本质上是一个质量过程，因此你希望最终结果是高质量的代码。有时开发者和审查者之间需要来回五轮，开发者提交更改，审查者请求修改，直到最终结果良好。你希望所有五轮都发生。但你希望每一轮都快速发生。如果每一轮都快速发生，你会发现PR审查时间只应该是那么长，开发者和审查者都对过程感到满意。

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

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

专注度（又称“心流”）

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

当开发者被彻底或太频繁地中断时，这种复杂的心理结构消失，当他们回到任务时必须重新构建。他们有可能忘记脑海中“接下来做这个”的事情，并因此实际交付损坏的软件。

我们称这种形式的中断为“上下文切换”，开发者的专注现在主要放在编写代码以外的其他事情上。当你强制开发者进行上下文切换时，可能需要十或十五分钟才能完全重建他们专注于编码时拥有的心理结构。因此小中断可能非常昂贵。

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

根据我的经验，如果中断引起不良情绪反应，它们也可能更具破坏性。对某事感到不安是如此分心，以至于很难保持专注于你正在做的工作。你觉得必须对不安做些什么，或者至少思考它。如果有人给我发送令人不安的消息，或者我的一个工具以极其令人沮丧的方式行为，那可能打破我的专注，即使中断只有5秒长。

如果你从事开发者体验工作并想改进心流，考虑诸如：我的工具是否强制开发者在执行这些任务时从事一些不是编码、测试或调试的复杂任务？我们是否确保开发者有多个不受干扰的小时来专注于编码？我的工具、系统或流程是否做了对开发者如此令人沮丧的事情以至于打破了他们的专注？

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

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

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

“认知负荷”是我不喜欢的一个术语，因为它不清楚是什么意思。为了开发者体验的目的，我们所说的意思是：开发者必须知道多少才能执行任务？开发者在执行任务时被迫做出多少决策？我将分别讨论这些点。

减少所需知识

有许多人认为开发者应该尽可能多地了解他们正在做的事情，我同意他们。然而，通过移除他们必须知道来做任务的事情，开发者的生产力和体验显著提高。当开发者必须写1和0来编码时，他们的生产力远不如现在。用汇编语言编写远不如用像Java或Python这样的高级语言编写生产力高。理解这些语言如何翻译成汇编是否使你成为更好的程序员？是的，确实。你是否必须知道这些才能做每个编程任务？不。

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

减少选择

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

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

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

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

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

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

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