打造卓越开发者体验的核心原则

我在"开发者体验"领域工作了20多年，通过改进工具、系统和流程来帮助开发人员提高效率和工作幸福感。我曾深入参与设计Google和LinkedIn的开发者体验关键方面，与该领域的研究社区保持密切联系，并不断与各大科技公司的开发者体验负责人交流。

基本概念

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

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

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

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

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

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

通常，加速大循环的方法是通过加速小循环。如果只专注于加速大循环，结果的质量往往会受到影响。

加速小迭代总是安全的（只要你发现它们确实存在问题）。例如，如果代码审查花费太长时间，通常你会发现审查者响应不够快。这里的解决方案是专注于审查者响应时间，而不是整体代码审查时间。

专注度（又称"心流"）

软件开发是一项需要长时间深度专注才能成功完成的活动。开发人员正在构建他们正在工作的东西的非常复杂的心理结构，并使用该心理结构做出决策和编写代码。

当开发人员被打断得太彻底或太频繁时，这种复杂的心理结构就会消失，必须在返回任务时重新构建。我们称这种中断形式为"上下文切换"，开发人员的注意力现在主要放在编码以外的其他事情上。

在我的经验中，如果中断引起不良情绪反应，中断可能更具破坏性。如果你从事开发者体验工作并想改善心流，请思考以下问题：

• 我的工具是否迫使开发人员在编码、测试或调试时从事一些复杂的非相关任务？
• 我们是否确保开发人员有多个不受干扰的小时来专注于编码？
• 我的工具、系统或流程是否做了让开发人员感到沮丧的事情，从而破坏了他们的专注度？

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

对于开发者体验，当我们说"认知负载"时，我们的意思是：

• 开发人员执行任务需要知道多少？
• 开发人员在执行任务时被迫做出多少决策？

减少所需知识

通过移除开发人员必须知道的东西来完成任务，开发人员的工作效率和体验得到了显著提高。

减少选择

开发人员只需要做出他们需要做出的选择。

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

开发者体验的挑战

开发者体验的大多数困难方面是人的方面，而不是技术方面。主要困难包括：

• 理解问题：现在改进开发者体验最重要的工作是什么？
• 管理变更：如何推出新变更？如何让人们采用新系统或行为？
• 提供杠杆作用：为开发人员构建的工具和系统不应需要太多工作来使用/采用它们，以至于它们实际创造的工作比节省的工作更多。
• 说"不"：你不能一次性解决世界上的所有问题。
• 将痛苦施加给造成痛苦的人：如果一个团队做了给另一个团队带来困难的事情，而制造困难的团队自己从未感受到任何困难，那么产生的痛苦将无限增长。

理解问题

这里最重要的是要知道问题来自用户，解决方案来自系统开发人员。你绝不能颠倒这种关系。

反馈和投诉

构建某些东西后，寻找有关系统的数据和反馈非常重要。在开发者体验领域，人们很少会向你发送正面反馈。当开发工具"正常工作"时，开发人员大多不会考虑它们。

管理变更

处理改进开发者体验时必须应对的主要因素之一是我们称之为"变更厌恶"。你对系统所做的任何变更在推出时都会收到某人的负面反馈。

增量推出

除了增量开发和设计之外，还必须知道如何增量推出变更，以便不是所有用户同时体验所有变更。这基本上有三个组成部分：

• 管理发布，使其尽可能减少干扰
• 选择良好的初始用户群进行推出
• 了解何时扩展群组以及扩展速度

推动采用

假设你已经很好地完成了增量推出，但就是无法让人们使用你的新东西。如何解决这个问题？

达到100%采用的唯一方法是让你的工具使用步骤为零。

提供杠杆作用

研究工具或改进开发者体验的整个重点应该是你为团队/公司节省的努力应该超过你创建和维护工具所投入的努力量。

为开发人员服务

如果你从事开发人员生产力工作，你的座右铭之一应该是"我们为开发人员服务，而不是开发人员为我们服务"。

说"不"

从事开发者体验工作的团队往往与客户关系密切。因此，当请求到达团队时，必须有一种方式提供以下三个答案之一：“是，我们现在就做”，“我们稍后会做”，或者"对不起，我们不会这样做"。

将痛苦施加给造成痛苦的人

如果一个团队可以做给另一个团队带来困难的事情，而制造困难的团队自己从未因此经历任何困难，那么产生的痛苦将不断增长。

解决这个问题的正确方法是改变谁必须做这项工作，这会改变团队的激励和基本"物理定律"。我发现最一致有效的规则是：

如果一个团队想要做出改变，他们负责代表公司执行该改变。

最后的话

这些就是我能想到的关于如何打造卓越开发者体验的所有基本原则。关于上述每一点，还有更多需要了解的内容，足够写一本书，或连续谈论十个小时（至少）。但上述内容涵盖了我此刻能想到的每个领域需要了解的所有核心概念。