什么是卓越的开发者体验？
作者：Max Kanat-Alexander（2025年4月15日）
我在"开发者体验"领域工作超过20年，致力于通过改进工具、系统和流程来帮助开发者提高效率、效能和幸福感。我曾深度参与Google和LinkedIn开发者体验的关键设计，与该领域的研究社区保持密切交流，并持续与各大科技公司的开发者体验负责人保持沟通。
本文将阐述打造卓越开发者体验的基本原则——该领域最需要理解的关键要点。由于涉及内容广泛，我将仅概述每个要点，但希望这能对核心观点提供良好的概览。
基本概念
优化开发者体验主要关注三个核心要素：
周期时间（又称迭代时间）：从开发者产生意图到实现该意图所需的时间。
专注度（又称"心流"）：开发者保持专注于当前任务而不被中断的能力。
认知负载（又称所需知识和决策）：开发者完成任务需要掌握的知识量以及需要做出的决策数量。
周期时间详解
软件开发包含大小不同的周期，即从开发者产生意图到结果在现实中实现的时间间隔。最小周期可能是"我打算写这行代码"或"我打算运行这个命令行工具查看输出"；最大周期可能是"我打算通过创建产品并让用户使用来解决问题"，或"我们打算用100人花一年时间重新设计系统"。
通常，加速大周期的方法是通过加速小周期来实现。如果只关注加速大周期，结果质量往往会受损。例如，如果某个团队需要两周才能将任何更改部署到生产环境，若简单地要求"不惜一切代价加快部署"，团队可能会采取损害最终结果质量和软件可维护性的捷径。
通过深入调查，你会发现存在耗时过长的小周期：代码审查响应缓慢、测试运行时间过长、部署工具难以使用等。加速小周期总是安全的（只要确认确实存在问题）。以代码审查为例，如果发现审查者响应速度过慢，解决方案应聚焦于缩短审查者响应时间而非整体审查时间。通常问题在于代码作者提交的PR过大，导致审查耗时过长。
代码审查本质是质量保证流程，需要保证最终代码质量。有时需要开发者和审查者进行五轮来回修改才能达成理想结果。关键是要让每一轮交互快速完成，这样PR审查时间就会保持在合理范围，双方都会对流程满意。
这一原则适用于软件开发的所有环节。如果发现编码耗时过长，需要考察构建时间、本地测试时间、决策信息获取速度等因素。每个周期都是某种形式的"观察-决策-行动"循环。改善开发者体验的最佳方式之一就是让开发者更容易观察信息——在需要时直接提供所需信息，同时避免提供无关信息（这会增加认知负载）。
专注度维护
软件开发需要长时间深度专注才能成功完成。开发者会构建复杂的心理模型来指导决策和编码，这种专注状态常被称为"心流状态"。当开发者被彻底或频繁打断时，这种心理模型会消失，需要重新构建，可能导致遗忘关键步骤甚至交付有缺陷的软件。
这种中断称为"上下文切换"，可能让开发者花费10-15分钟才能重新进入编码状态。即使短暂中断也可能造成巨大成本。中断的影响因人而异（30秒到2分钟），也取决于中断性质：简单的手机通知可能不会打断心流，而复杂的错误警报则可能立即破坏专注度。
情绪反应也会加剧中断影响。令人沮丧的工具行为或消息可能瞬间打破专注。为改善心流，需要考虑：工具是否强制开发者在编码时执行复杂非编码任务？是否保证开发者有连续数小时不受打扰的编码时间？工具是否引发挫败感？
另一个关键点是开发者是否清楚工作的目的和方向？明确的任务说明能避免因困惑导致的专注中断。理想情况下，应该将清晰信息直接呈现给开发者，避免让他们中断工作去寻找所需数据。当然，如果"学习新知识"本身就是任务目标，那么信息搜索就不算中断——只要能够轻松找到所需信息。
认知负载管理
认知负载指开发者完成任务需要掌握的知识量和必须做出的决策数量。
减少必备知识：虽然开发者应该尽可能了解工作内容，但减少必备知识能显著提升生产力和体验。从二进制编码到汇编语言再到高级语言的演进历史证明了这一点。大多数公司的开发者基础设施团队容易陷入的误区是：要求开发者深度掌握工具知识才能开展工作。理想情况下，每个工具都应该足够直观，无需学习就能使用，最好能重新设计基础设施让开发者除非必要根本不需要使用该工具。
减少选择：这是最具争议的方面，但根据多家公司的经验，可以确信：开发者只需要做出必要的选择。虽然开发者希望拥有完全自主权（选择编程语言、包管理器、构建工具等），但大多数时候这些决策会分散团队对核心任务的注意力。极端情况下，如果每次修改系统都需要重新研究所有技术选型，将永远无法完成实际工作。
在公司内部，甚至应该禁止开发者做出非必要的决策。这听起来极端，但正确实施能带来卓越的开发者体验。问题在于开发者可能意识不到某些决策的长期后果。例如，不允许随意选择编程语言——这会导致他们需要开发新库和基础设施而非专注实际任务。
但必须谨慎平衡：开发者需要被允许做出必要的决策。每个人的工作方式差异很大，对工作流程施加过多硬性约束会损害生产力。好的做法是：“我们将为主要编辑器提供更多支持，但所有功能都会以命令行工具形式暴露，方便自由选择。”
如果基础设施限制了开发者的决策权，就需要集中维护好该基础设施。中央团队需要持续负责这些决策的结果。有时需要提供有限选项，比如单纯要求"所有项目都用Java"显然不切实际。
成功的关键在于深入理解开发者需求和他们所处理系统的要求。需要了解他们解决的问题类型，才能知道哪些决策是必要或非必要的，并能够随时间适当调整策略。
大多数开发者并不希望为每个系统决策费心，他们热爱编程是因为能够指挥计算机解决问题并帮助用户。应该让他们专注于实现这一目标，而非陷入软件工程宇宙中的所有可能决策。
开发者体验的挑战
开发者体验的大多数困难属于人为因素而非技术因素。主要挑战包括：
理解问题：当前最需要改进哪些方面？如何充分理解问题以构建正确解决方案？
管理变更：如何推出新变更？如何让人们采用新系统或行为？如何处理对变更不满的人员？
提供杠杆效应：为开发者构建的工具系统不应该产生比节省工作量更多的工作。
学会拒绝：无法一次性解决所有问题，需要优先级排序。有时团队要求的工具或功能实际上会损害公司整体开发者体验。
让制造问题者承担痛苦：如果一个团队的行为给其他团队造成痛苦，而制造问题的团队从未感受到任何后果，痛苦将无限增长。
变更管理策略
变更厌恶是改善开发者体验时需要应对的主要因素。任何系统变更都会在推出时收到负面反馈，这通常不是因为变更本身有问题，而是用户习惯了原有工作方式。
识别变更厌恶与有价值反馈的方法包括：变更厌恶通常持续3-10天；变更厌恶反馈通常带有情绪化特征。管理变更时要避免引发大规模抵制。有疑问时，应该以较慢的扩展速度向较少用户推出较小变更。
但绝不能将所有反馈都归因于变更厌恶。如果多人提供相同的事实反馈，且反馈合理，改进产品能带来提升，这很可能不是变更厌恶。即使认为是变更厌恶，也应该至少承认反馈，让用户感到被倾听。
渐进式发布：除了渐进式开发和设计，还需要知道如何渐进式发布变更。这包含三个组件：尽可能减少破坏性的发布管理；选择合适的初始用户群；把握扩展时机和速度。
最小化破坏意味着：不破坏用户系统；不要求用户手动适应变更；必要时提供清晰文档；确保系统提供明确错误信息。选择初始用户群主要考虑谁能提供有用反馈以及需要多少用户才能获得这种反馈。扩展速度取决于反馈量、每个新团队所需的手动支持量、变更的破坏性程度等因素。
推动采纳：确保真正理解问题，且该问题是开发者知晓并希望解决的。然后确保解决方案能真正处理该问题，不会给开发者带来新问题。需要倾听并处理反馈。
实现100%采纳的唯一方法是让工具达到"零步骤使用"：将功能直接嵌入工作流，而非让开发者执行新操作。如果使用需要一步，可能达到80%采纳率；需要两步，可能只有30%；如果需要阅读长文档遵循复杂说明，就很难有人使用。
但不应从一开始就追求零步骤使用——这在工具生命周期早期工作量过大。早期可以接受较难采用的工具，因为只提供给小型热情群体获取初始反馈。一旦工具完善，“零步骤"就成为推动100%采纳的 mantra。
提供杠杆效应
开发工具或改进开发者体验的核心目的是为团队/公司节省的努力应该超过创建和维护工具所需的努力。即使工具主要关注工作质量而非速度，也需要考虑没有该工具要达到相同质量结果需要多少工作量（有时答案是"无限”，因为不可能在没有工具的情况下达到那种高质量）。
在软件中，减少维护努力比减少创建努力更重要。因此不仅要考虑工具的即时影响（和构建成本），还要考虑长期节省的努力（和维护成本）。不同公司有不同的"时间范围"进行计算——如果现在投入X小时，在Z年内为公司节省Y小时总努力。Z就是时间范围，即公司愿意考虑多长时间内的节省。在Google，我们通常将时间范围设为两年，任何开发者生产力投资都必须在两年内"回本"。
人力时间：这个领域最常见的错误是通过某些优化节省机器时间（CPU使用、内存使用、磁盘空间随时间推移的成本），而忘记了节省了多少人力时间。大多数情况下，一小时人力时间的成本比所涉及的所有机器时间成本高出数百倍。有充分理由优化机器时间，但改善开发者体验很少是其中之一。考虑开发者生产力改进的成本和价值时，应首先考虑节省了多少人力时间。
服务开发者：如果从事开发者生产力工作， mantra 之一应该是"我们服务开发者，而不是开发者服务我们"。很容易发布让开发者做更多工作的工具，这些工具可能让他们填写本可自动化的表单信息，或者暴露需要学习的复杂实现细节，而不是让开发者表达意图后由系统完成工作。虽然让工具以这种方式工作需要更多工作量，但发布让开发者完成所有工作的东西会违背我们提供杠杆效应的初衷。
优先级管理
从事开发者体验的团队与客户关系密切，客户可能包括公司高级领导。开发者通常对需求有强烈意见且面临时间压力。但基于每日小时数、设计良好解决方案所需时间、解决问题的人员数量等因素，开发者体验能完成的工作量有限。
因此，当请求到达团队时，需要提供三种答案之一：“是，我们现在就做”、“我们稍后做"或"抱歉，我们不会做”。
立即执行：开发者体验领域存在大量合法且有价值的计划外工作。通常是对工具系统的小型无争议修复，可以在一两小时内处理。也有些工作需要一两天但能提供即时明显杠杆效应，无需等待规划流程。为了能够对少量即时工作说"是"，必须在规划过程中留出计划外工作时间。如果季度计划分配了团队100%的时间，会破坏与公司其他部门的关系。
但任何团队处理即时工作的能力都有限，团队成员需要了解能对多少即时工作说"是"，何时应该回答"稍后"或"不"。
稍后处理：对于需要超过几小时或几天的工作、需要需求研究、可能有争议、难以推出等情况，需要建立接收客户请求并确定优先级的流程。开发者体验团队及其经理不能对每个请求都说"是"，否则永远无法交付高质量高价值成果，总是疲于应付即时问题，交付半成品解决方案，然后解决这些半成品引发的新问题。
优先级排序应基于对问题的理解、解决方案提供的杠杆效应以及创建和维护解决方案所需的总工作量。棘手之处在于开发者体验团队的工程师通常是接收这些请求的"前线"，需要有礼貌地将请求推迟到"稍后"类别（通常称为"待办列表"）。工程经理、产品经理和项目经理需要建立明确的流程，让基层工程师不会因说"稍后"感到尴尬。
大多数客户能接受"稍后"，只要大致知道何时能得到结果。不需要为所有请求提供确切日期——远期可以说"明年"，近期客户可能希望更精确日期，但大家都应理解软件工程中的交付日期总是估算值。绝不能强迫开发者体验团队为满足任意期限交付劣质产品——劣质解决方案给公司带来的成本远高于多等一周让团队构建更好产品。
明确拒绝：对客户说"我们永远不会做这个"是最难的回