如果开发人员感到沮丧和精疲力竭，不要猜测，直接询问他们需要什么来提高满意度和生产力。
译自 Top Problems Developers Need You To Fix Now，作者 Steve Rodda。
许多软件开发人员从小就开始摆弄代码，并一直坚持下去，最终将其变成了职业。编写一个有效的函数或成功地排除一个棘手的bug的快感与年龄无关——富有成效的感觉很好。
与此同时，令人惊讶的是，大量开发人员在工作中经历了倦怠。这是许多组织中的一个重大问题，而成本对于开发团队来说可能异常高昂。
如果开发人员喜欢自己的工作，为什么还会倦怠呢？关键在于，开发人员每天只有10%的时间在编写代码。科技行业多年来一直在努力解决这个问题。2009年，Y Combinator的创始人Paul Graham呼吁科技管理层更加关注“创造者的时间表”，并减少由管理人员驱动的中断造成的开销。
如果说有什么不同的话，那就是创造者的时间表现在比15年前更加碎片化了，因为全球化、容器化和威胁参与者等复杂因素的增多。公司试图通过投资于工作场所文化、项目管理工具和承诺提供更好开发人员体验的产品来进行补偿，但这些努力并没有奏效。科技员工的倦怠率已从2018年的约57%上升到2024年的高达71%。
现在是时候采取不同的方法，找到问题的根源了。如果开发人员感到沮丧和倦怠，我们应该与他们讨论如何改善他们的工作条件。下面，我将介绍一些常见的挑战，并向你展示如何采取以开发人员为中心的方法来解决这些挑战。
在是否关注开发人员生产力或开发人员体验的争论中，一个关键点经常被忽视：当人们更快乐时，他们会做更多更好的工作。如果团队想要提高生产力，他们应该首先了解是什么阻碍了单个开发人员。
我们最近在API World与经验丰富的开发人员和工程领导者进行了交谈，并向他们提出了一个简单的问题：“你们在2024年的API痛点是什么？”
答案与我们多年来听到的一致，对于任何在该行业工作过的人来说都耳熟能详。我们交谈过的人心中有不同的问题，但它们往往属于五大类：简化数据访问、改进协作、改进安全性、构建一致性和发现性以及获得对API程序投资的支持。
这些都是开发人员的生产力障碍——占据他们宝贵时间和精力，使其无法进行编码的工作方面。这些普遍存在的问题不成比例地增加了开发人员的认知负荷，从而增加了倦怠感，降低了生产力和满意度。
API比以往任何时候都向更多用户提供了更多数据。但是，可用的数据可能并非人们真正需要的；有时，它格式不可用，或来自地理位置受限的区域。除了访问问题之外，重复数据以及不一致的格式和协议通常会占用API团队过多的时间。
- 理解你的数据管道: 设计数据模型的团队需要了解数据的消费、生成和使用方式。你的数据是否可追溯？是否可变？你在不同阶段如何验证数据？数据对象的生命周期和寿命是怎样的？仅仅生成满足一项规范的数据是不够的；大型复杂组织需要能够在其整个生命周期中处理大型复杂数据的API。
- 改进数据建模: 数据管理在开发和生产过程中都是一个需要关注的问题。通过更深入地了解你的数据管道，你获得的知识应该指导你在API生命周期的早期阶段如何建模数据。了解你的数据将如何使用可以帮助你选择合适的数据结构，设计合适索引策略并优化读写操作。数据模型可以帮助你在未来的迭代中维护数据完整性和性能。
- 保护你的数据: 数据安全和合规性比以往任何时候都更加重要。黑客方法越来越复杂，风险也越来越高。适当的安全措施，包括加密、身份验证、授权和数据验证，对于API程序的长期生存能力至关重要。
这引出了API团队面临的下一个重大障碍。
超过40%的API World与会者将安全问题列为他们最大的困扰（基于Ambassador团队在会议期间进行的一项调查）。这个问题是常青的：API安全永无止境，因为威胁环境总是在变化。如果你忽视安全，你很快就会付出代价。到目前为止，大多数科技行业人士都接受了这一现实。
挫败感——就像它经常发生的那样——会在安全措施不一致、耗时且复杂时产生。结果，用户开始规避安全措施。有些违规行为很小，例如密码重用。另一些则更为严重，例如共享管理员凭据。还有一些会完全破坏你的网络安全和数据完整性，例如销售人员在演示中使用实际客户数据。
这些问题并非由不良行为者造成——它们之所以发生，是因为安全策略过于繁琐，妨碍了人们完成工作。
最佳安全策略是可以在你整个组织中一致实施，并且员工会遵循的策略，因为它们涉及简单实用的流程。对于API程序，这通常意味着使用API网关。
对API网关进行身份验证可以通过单次登录访问许多宝贵的资源。登录过程的逻辑简单明了，因此员工不会有规避它的诱惑。它还可以追踪用户活动，并在需要时更容易撤销凭据。
API开发人员知道他们需要协作。对于API作为一项技术来说，这几乎是内在的——“I”代表接口。如果你正在构建一个对双方都有效的接口，那么你需要从一开始就进行沟通。
但是，仅仅因为协作是必要的并不意味着它很容易。许多API驱动的组织中工具的激增可能会妨碍人际沟通。人们需要与人交谈，而不仅仅是与工具交谈，而API开发平台应该通过打破孤岛和简化工具链来使这更容易管理。
虽然API文档当然是解决方案的一部分，但优先事项应该是减少协作的痛苦。你可能会发现改进空间的一个领域是缩短开发人员在开发新功能时的反馈周期。
当开发人员将更多时间花在内部开发循环中时，他们的生产力更高，并且可以更快地整合新想法。反过来，他们可以更快地与用户分享挑战和想法，从而使他们能够更有效地一起工作。
容器化对外部利益相关者来说是一个福音，但它会大大减慢单个开发人员的速度。最佳的基于容器的开发环境允许开发人员以很少的开销访问临时环境，从而使他们能够更长时间地停留在内部开发循环中。 寻找一个API管理工具，它可以轻松访问可共享的模拟服务器和完整的IDE集成。这有助于开发人员在类似生产的环境中构建和测试API端点，而无需依赖冗长的构建过程。此类改进显著减轻了开发人员的认知负担，使他们能够更专注于最关键的工作。
我们从工程领导那里听到的另一个挑战是在一系列API中交付一致的代码。如果您希望代码顺利运行，确保单个API内的一致性至关重要，但大多数组织在其应用程序中使用和生成数十个API，这使得一致性更具挑战性和重要性。
一致的API功能和数据模型很重要：
- 不一致的代码几乎总是安全性较低: 当您的API具有不同的身份验证协议时，您如何知道自己遵循最佳实践？
- 不一致的API = 开发人员的辛劳: 当面临缺乏一致且可访问的API目录时，访问API通常是许多开发人员面临的令人沮丧的起点。
- 用户能够预测API的工作方式时，他们会更加成功: 没有人想阅读和理解他们使用的每个API的文档。开发人员倾向于将少数端点和方法推广到其他API——您需要确保这不会适得其反。
- 从设计到生产的高效协作: 开发人员是否构建了他们最初所说的内容？交付的数据是否符合用户期望？您的数据格式在所有读/写操作中是否一致？
- 规划未来的更新和版本控制: 为了了解用户在不引入新版本的情况下可以容忍哪些更改，您必须准确了解您在当前所有API中交付的内容。不一致会使这成为问题。
- 当人们知道他们在寻找什么时，发现更容易管理: Microsoft Excel 的软件支持团队过去常常处理数千个针对已可用功能的功能请求。问题在于可发现性：Excel 功能非常丰富，但菜单和工具栏一直在不断增长——更不用说混乱不堪——没有人能找到他们需要的东西。大型API组合也会发生同样的情况；不一致只会加剧问题。
- 当API易于比较时，可观察性更容易: 如果您想比较不同API或端点的性能和使用模式，请记住科学控制的原则。如果您的API不一致，则无法进行有意义的比较，也无法将从一个资源中获得的宝贵经验应用于另一个资源。如果您控制格式并执行治理，您会发现更容易理解差异。
您的API需要协议和标准，您的团队需要工具来促进治理和合规性。一个设计良好的平台包括像样板代码生成这样的自动化工具来完成一些繁重的工作。
同样，您希望您的开发人员专注于创新和迭代他们的代码。寻找减少枯燥工作和手动检查负担的方法，您将消除开发人员日常工作中的大部分苦差事和疲劳。
导致开发人员倦怠的一个常见因素是他们感觉自己的工作没有得到重视。如果领导对倡导API的价值缺乏信心，他们的团队就会遭受下游影响。但是，如果领导者是有效的倡导者，开发人员就会受益于看到他们工作的成果，并感觉自己是组织中受重视的一员。
幸运的是，从商业角度来看，不难找到喜欢API的理由。有些将是您组织独有的。您需要充分了解API的用例，并能够解释您如何满足这些需求。
好处也可能更广泛：
API从现有数据中创造新的价值
通过将数据分解成更小、更专用单元并在自助服务的基础上提供，API 使更多人能够使用数据。API还允许用户控制他们的成本，这有助于您吸引更广泛、更可持续的客户群。
构建API可以很快
在一个对开发人员友好的平台上构建API可以更快。开发人员可以快速迭代新想法，从而使他们能够以很少的开销测试新功能和商业模式。
API让您控制如何使用AI——以及如何不使用AI
每个人都需要规划如何使自身的流程和产品适应AI。虽然基于AI的专业工具能带来很多价值，但基于AI的产品仍然相当值得怀疑。
你的API开发团队可以使用AI来提高工作流程中多个阶段的生产力，而不会影响API产品的完整性。这比大规模的AI产品发布更经济高效，也是熟悉AI的可能性和局限性的好方法。
记录你的API流程改进对于为你的API项目进行论证至关重要。我们关注单个开发人员的体验，因为开发人员在编码、构建和测试的内部开发循环中效率更高。他们也更快乐，从长远来看，这将带来更好的业务连续性和降低员工入职成本。
工程领导者需要发声：API团队正在为他们的组织创造巨大的价值，并且可以通过有效解决他们最大挫折感的工具和流程来做得更多。
上述挑战清单相当庞大。解决这些问题可能感觉令人望而生畏，尤其是在你试图一次一个地面对它们时。幸运的是，你不需要这样做。
产品管理方法应用于API是令人精疲力尽且适得其反的；一次做太多事情会导致浪费精力和资源。API开发受益于一种整体方法，这种方法可以减少摩擦，提高开发人员的生产力，并减轻压力和认知负担。团队必须超越一次性解决方案，重新思考API管理模式。
与直觉相反，答案是尝试少做——结果你会完成更多的事情。在Ambassador，我们鼓励API团队将他们的重点从API产品管理转移到一个更具体、更相关的作业单元：端点。
API即产品并非一个坏概念，但其真正的重点是API使用者。这只是管理开发人员工作流程的一种不好的方法。内部开发循环需要一种内部关注的管理方法，这意味着要重新关注API开发人员所做的独特工作——即一次编写和调试一个端点的代码。
如果你想采取比端点管理略微广泛的方法，平台工程是一种DevOps和工具方法，它从类似的想法出发。许多DevOps和开发者工具程序都是围绕站点可靠性工程师（SRE）的需求设计的。SRE们做了非常有价值的工作，但他们的关注点是外部的，致力于确保向客户提供一致的服务。平台工程将重点转移回构建API的工程师的日常工作流程。
端点管理和平台工程之所以有效，有几个原因。它们通过减少非编码工作负载来减轻开发人员的认知负担。它们允许团队更紧密地遵循“创造者时间表”，提供更长的专注工作时间段。并且它们减少了围绕解决实际开发人员自我报告的挫败感而设计的工具带来的不必要的摩擦。
满足开发团队的独特需求可以自给自足，特别是当你选择的工具精简、专用且对开发人员友好时。这种单一方法可以预防和解决许多最常见的开发人员抱怨，从而提高开发人员的体验和生产力。
API开发永远不会没有痛苦，但识别出最大的日常障碍可以帮助团队朝着正确的方向前进。当你更改API团队的流程和工具时，目标应该是减少开发人员的辛劳：将控制权交给开发人员，以便他们能够解决最影响他们的摩擦。
如果你能帮助你的开发人员做出这种转变，你将看到巨大的回报。他们将编写更多更好的代码，并体验更少的倦怠。为开发人员提供使他们更高效的工具。他们将构建更强大的API，并且在构建过程中会更快乐。