共计 5391 个字符，预计需要花费 14 分钟才能阅读完成。
引言
近期在参加编写平台工程系列规范时，我发现开发者体验 (DevEx) 是一个不可漠视的关键因素，它对于构建一个胜利的平台工程起到了重要的作用，DevEx 能够称之为平台工程的根底。基于我最近的学习和思考，我决定写这篇文章，想深入探讨一下 DevEx 对于外部开发平台的重要性，也心愿为从事外部开发平台的同学们带来一些新的思考。
理解平台工程
平台工程是设计和构建工具链和工作流的学科，可在云原生时代为软件工程组织提供自助服务性能。平台工程师提供的集成产品通常被称为“外部开发人员平台”，涵盖了应用程序整个生命周期的经营需要。– 定义来自 platformengineering.org
对于平台工程的定义和思考，我在上一篇《扯淡的 DevOps，咱们开发基本不想做运维！》文章也提到了，对于定义目前尽管从文字内容上有些差别，但大部分的意思较为统一：次要是提倡自助服务，将底层根底撑持工具的复杂性和不确定性去缩小，减化工作流程，最终用户在应用过程中的认知老本升高，从而 改善了最终用户的体验，和进步生产效率。
为什么须要平台工程
在公司外部，有负责中台的研发团队，有负责前台的研发团队，还有团队专一于开发者平台的研发。这些从事外部开发者平台的同学，实际上就是平台工程团队。与其余团队相比，平台工程团队最大的区别在于他们须要具备产品思维。这些团队的同学能够称做平台工程师，那么 每个平台工程师起码是个兼职产品经理。
然而，在理论状况中，这些平台工程师可能过于专一于技术实现，而会疏忽用户的需要和反馈。他们可能会认为本人负责的工具平台本人是最理解的，因而很少会去调研真正用户的需要和反馈，日复一日一直地开发新的产品和性能。
这里抛个问题，能够思考一下：为什么企业在抉择上云时，往往不间接应用私有云控制台，而是通过企业的云管平台提供服务呢？
外表来看，间接应用私有云控制台仿佛是最简略高效的抉择。然而，当应用当前咱们深入分析后发现，这种抉择可能会带来一系列的重大问题。最终可能会造成资源节约、资源安全性问题。另外，应用私有云控制台的应用老本也较高，从而也升高了用户的体验。
在平台工程的提倡下，应该升高开发人员的认知负荷和应用老本，企业通过 云管平台 来提供服务，能够无效升高开发人员应用认知老本，晋升用户的体验，让开发人员可能更专一于构建本人的应用程序。
理解 DevEx
开发者体验 (DevEx) 指的是软件开发人员在日常工作中遇到的整体环境、工具、实际和文化。它涵盖了从设置开发环境的便捷性，到工作流程的效率，到工具和流程的有效性，以及整体的反对其创造性和技术致力的工作文化。
一个最常见的误会是，开发者体验 (DevEx) 次要受外部开发者工具的影响。然而，依据调研发现，除了工具因素外，环境因素和人为因素同样对开发者体验产生重大影响。
环境因素包含办公环境、团队文化等。一个良好的工作环境可能激发创造力，进步工作效率。例如，一些公司为了营造轻松愉悦的办公气氛，提供了各种娱乐设施，如啤酒桶、咖啡角、弹球台、乒乓球台等设施，旨在让开发者缓解工作压力，有助于晋升开发体验。
另外，我的项目的稳定性、指标的明确性、绩效考核形式的清晰性也是影响开发者体验的重大因素。如果我的项目团队常常调整组织架构，我的项目指标不明确，绩效考核 A/A+ 的定义模糊不清，开发人员会感到十分困惑和不安，会极大影响研发同学的工作效率和体验。
因而，DevEx 是平台工程的基石，是促成开发人员效率晋升的最佳门路。
DevEx 在平台工程中的意义
晋升开发人员的效率始终以来都是一个谋求的指标，但如何掂量开发人员的效率却始终是一个难题。仅仅谋求需要交付周期或开发交付周期是绝对比拟全面的，未能思考到开发人员的工作是一个简单且多样化的工作。那么，怎么来掂量开发人员的生产力呢？
然而，一些企业在谋求进步开发人员生产力方面获得了一些发现，他们发现重视开发人员的体验，以开发人员体验为指标的办法（DevEx）能够极大地促成开发人员的效率。依据 Gartner 的调研报告，78% 的受访企业曾经制订或打算制订 DevEx 晋升打算。DevEx 提供了一个度量框架，该框架将开发人员的反馈、认知负荷老本和专一水平综合在一起，为开发人员提供了清晰、可操作的掂量维度。
在平台工程畛域，DevEx 是一个至关重要的因素。关注它不仅能够进步开发人员的工作效率，还能够放慢交付周期，并晋升开发者的幸福感。通过关注开发人员的体验和提供良好的工具和环境，企业为开发人员发明一个舒服且高效的工作环境，从而能够进步整体的开发效率和品质。
落地 DevEx
DevEx 是最大化晋升开发效率的要害，假如你是平台工程团队，不晓得有没有被动思考过一个问题：“为什么开发人员不违心应用咱们的工具？”，作为平台工程团队肯定要牢记以下 7 个办法：
1、理解你的用户（开发者）
“顾客就是上帝”，尽管咱们不是甲乙方，尽管咱们同在一家公司，甚至一个办公室，但你是否真的理解用户的需要？你是否将用户视为上帝？是否真的理解用户的需要和痛点？
在平台工程团队，理解用户诉求，不仅仅是产品经理的职责，更应该是整个平台工程团队的工作，不仅要理解用户痛点，而且还要分明晓得用户平时都是以什么形式在应用你的平台。
•线上考察问卷：考察问卷是最间接的渠道，能够定期被动收集用户的心声。
•线下培训流动：面对面的产品培训，或通过用户访问以及其余形式，面对面收集用户的意见。
•放弃好奇心：多关注用户群、神灯畅聊的音讯，当听到有埋怨或吐槽声音，要及时跟进解决并思考。
2、向专职 UX 岗位学习
如果把开发人员当初用户来看的话，其实 DevEx 要做的事，和公司内的专职 UX 岗位同学的职责差不多。UX 岗位大部分精力都在和用户沟通调研，最终造成用研报告。
“惟一好的假如就是咱们的假如是错的”，我特地喜爱这句话，讲的十分有情理，因为当咱们开始假如的时候，咱们就曾经错了。通过假如做出了某个需要的时候，要么是没人须要的性能，要么是解决了没有人遇到的问题。因为所有的性能，都应该是发现进去的，而不是假如进去的。性能都是通过：发现、设计、开发、交付这 4 个阶段，但最难的就发现问题，通常 UX 岗位同学在用研过程中是最容易发现问题的。
3、以用户为核心的心态
任何产品都应该以用户为核心，在平台工程团队更加重要，因为经常咱们本人也是用户，特地容易把角色搞混，所以更应该时刻强调，谁才是真正的用户，且要时刻确保这种心态。
•肯定不要假如用户的需要。
•所有的需要用用户视角去形容，解决【哪些用户】的【什么问题】，将需要的指标转移到用户身上。
4、自动化你的零碎
自动化在晋升 DevEx 方面具备重要作用，无论是在老本、效率还是稳定性方面。通过自动化工具和流程，都能够主动实现繁琐的工作，缩小开发人员的累赘。例如，自动化构建和部署流程能够缩小手动操作的谬误，并放慢交付工夫。自动化测试能够进步产品质量和稳定性，缩小问题的呈现。此外，自动化还能够帮忙进步产品的一致性，缩小人为因素的影响，进步稳定性和可靠性。
总的来说，自动化在晋升 DevEx 方面是至关重要的。通过缩小手工环节和自动化流程，能够升高用户应用产品或工具的步骤，从而进步开发者体验。
5、明确岗位和职责
在过来，大部分公司外面有这样一个岗位，叫 SCM 工程师或者配置管理工程师，但这些年随着 DevOps 的倒退，自动化构建和继续集成 / 继续交付的成熟，开发人员通常会通过工具自动化实现这些工作，从而缩小了专职的需要，因而这个岗位或者叫法正在缓缓隐没。
目前，在公司中负责平台或者工具的团队，尽管有专职的团队，但岗位名称大部分依然是前端 / 后端软件开发工程师岗，这就无奈明确这部分同学的具体职责，但尽管平台工程的倒退和推动，目前在一些公司中，曾经有一些叫平台工程师这个岗位角色，这个角色正在逐渐代替测试开发、工具开发、运维开发、甚至代替 SRE 的岗位角色。因而，我感觉通过明确的岗位和角色，能够更好明确岗位对应的具体职责，更好推动平台工程的落地。
6、Shifting down
在软件开发过程中，通过转移的形式，将开发人员身上的职责进行加重，通过转移到其余角色或者平台上，从而升高开发人员的累赘，从而晋升 DevEx。
左移：将测试左移，测试在开发过程中晚期阶段进行，能够更早发现和解决 Bug，应用自动化测试工具或者测试框架来验证代码，不过这种做法对测试要求较高，如果测试人员能力达不到，一味地推动测试左移，甚至可能会给开发减少累赘哈哈。
右移：上线成果 A / B 试验，通过比拟试验的办法来验证上线性能成果。
下移：下移的整体思路就是将开发人员从工具和平台中解放出来，平台工程师负责构建和保护工具平台，为开发人员提供稳固的基础设施和工具，这样，开发人员能够专一于业务逻辑和翻新，能够放慢开发速度，从而也晋升了 DevEx。
7、建设掂量 DevEx 的指标
最初一点，是建设 DevEx 指标，从而掂量 DevEx，并晋升 DevEx，诚实说这点的确比拟难，但想一想业务开发团队都能指定一些 KPI 去掂量，那么平台工程团队也应该这样做，或者能够说能够尝试这么做。
度量 DevEx
巨匠彼得·德鲁克说过：“如果你无奈掂量它，你就无奈治理它。”，在 23 年公布的一篇钻研论文中揭示了度量和晋升开发者生产力的一种全新框架，该框架称之为 DevEx 框架 ， 作者为 Abi Noda、Margaret-Anne Storey 博士、Nicole Forsgren 博士、和 Michaela Greiler 博士。
影响 DevEx 的因素
针对开发效率或开发者生产力的度量，为什么始终以来都比拟艰难，次要有两大起因：一方面软件开发的过程是不可反复且创造性的工作，另一方面开发人员在工作中容易受到内部烦扰的影响。
①软件开发过程非标准：软件开发的过程不是重复性的劳动，且是创造性的工作，产出物并非规范的可掂量的，无奈通过掂量流水线车间工作一样的方法来掂量软件开发工作。
②内部烦扰的影响：除了公司提供的工具效率影响外，也还有开发我的项目的难易水平、开发者和其余角色的沟通老本、历史代码的技术债权等因素都会影响开发效率。
DevEx 框架 提出了反馈周期、认知负荷、专一状态三个维度。提倡通过关注这三个维度，从而推动开发者生产力的进步。
•反馈周期：在开发过程中，能够疾速的反馈对于提供开发人员的工作效率至关重要。例如，构建、测试或开发环境设置效率低下，导致反馈周期缩短，将间接影响开发人员工作的积极性和生产力。
•认知负荷：在开发过程中，如果开发人员须要破费大量工夫了解代码、了解工具的应用办法或者查找文档上，这会导致认知负荷减少，从而影响工作效率。
•专一状态：在开发过程中，如果开发人员频繁被打断或烦扰，不能进入到专一状态，那么生产力就会收到重大影响。咱们的“No meeting day”其实也是组织为大家可能进入到专一状态的一种伎俩和形式。
掂量 DevEx 的指标
对于晋升开发者体验，掂量指标是十分重要。下图是 DevEx 框架提供的一个示例，用于理解以后存在的问题，从反馈周期、意识负荷、专一状态三个维度进行评估。倡议在每个维度上抉择要一两个要害指标进行度量。同时，也须要从全局上思考，制订一些宏观指标，如员工满意度、需要交付周期等，作为全局考核的北极星指标。
为了掂量开发者体验（DevEx），须要综合思考主观和主观数据。除了从相干工具或零碎中获取主观数据外，还须要考察开发人员的认识、态度和意见。这些主观的数据在某些状况下能够提供绝对精确的反馈。
例如，只管构建过程可能十分高效，但如果构建操作的步骤过于简单，可能会烦扰开发人员并影响其体验。因而，从整体构建过程的角度来看，开发者体验可能绝对较差。这种主观反馈能够补充主观数据，提供更全面的视角。
除了反馈周期，认知负荷对开发者体验的影响最大。认知负荷能够从两个状态来看：
•进入状态：这是开发人员齐全投入并享受工作的状态，通常须要约 23 分钟的工夫来进入。如果频繁中断这种工作状态，例如交叉其余工作，那么进入状态所需的工夫可能会更长。
•期待状态：例如期待从新编译、期待代码评审、期待部署、期待服务启动等。这些期待状态的累计工夫将形成认知负荷的一部分。
常见的 DevEx 度量指标。例如，能够抉择度量自动化测试效率（反馈周期）、均匀部署时长（反馈周期）、执行门路数（认知负荷）、可抉择操作数（认知负荷）、代码库复杂性（认知负荷）、技术债权（认知负荷）和深度工作工夫（专一状态）、XX 自动化率（综合维度）、平台 NPS 满意度值（综合维度）。
通过综合思考以上指标，能够帮忙组织更好地发现实在的开发者体验，找出可能存在的问题，并针对性地进行优化，通过一直地改良和度量，从而晋升 DevEx。
结语
依据 StackOverflow 的考察，约有 62% 的受访者每天破费超过 30 分钟的工夫在搜寻答案和解决问题上，而 25% 的人甚至破费超过 1 小时。此外，依据 CNCF 云原生的 Landscape 展现，目前已有 2000+ 张卡片，笼罩了各个维度的能力，但这也导致了开发人员认知累赘的日益减轻。
在公司外部，咱们目前领有行云、泰山等各种开发者工具。然而，这些工具对于开发者在反馈周期、认知负荷、专一状态方面依然有很大的晋升空间。因而，心愿咱们所有的平台工程团队，都能致力于实现晋升 DevEx 为指标，2024 咱们一起加油💪🏻！
作者：京东批发 井亮亮
起源：京东云开发者社区 转载请注明起源
