开发者生产力不在于拥有 50 种工具，而在于使用合适的工具来改善体验、提高速度和生产力。
译自 Optimizing for Developer Productivity Creates a Winning DevEx，作者 Matt Voget。
开发者经常面临着满足业务目标和保持卓越运营的双重压力。但亲力亲为（有些人提倡）并不总是能转化为更好的开发者体验 (DevEx)。
我们在每次主题演讲、博客文章和供应商宣传中都听到很多关于 DevEx 的信息——这个术语开始失去其意义。不要误解我的意思，DevEx 很重要。但是，虽然它经常被作为一个广泛的概念来讨论，但专注于切实的生产力改进——比如简化编码、测试和调试的循环——会带来更直接和可衡量的结果。
开发者生产力 (DevProd) 并不是指拥有 50 种工具可供使用。而是通过合适的工具来改善体验、速度和生产力。有了这种心态，就更容易专注于真正赋予开发者权力的事情——消除障碍，创造一个他们可以专注于构建卓越软件的环境。
以我的经验来看，DevProd 的核心在于我们在 Ambassador 所倡导的“ 优化内部开发循环以提高开发者速度”。开发者在处理功能或消除错误时执行的核心活动周期。它是以下流程：
- Writing code
- Building the application
- Running and testing
- Debugging
- Committing code
这个循环重复进行，有时一天重复几十次——编码、构建、测试和调试的核心循环。这个“内部开发循环”越顺畅、越快，开发者就越有效率。他们可以更快地迭代，更快地解决问题，并以更快的速度开发功能。
但这并没有发生，因为存在“外部开发循环”，相比之下，它包括更广泛的开发生命周期，包括但不限于计划、协作、集成和部署等任务。这会加剧摩擦并增加上下文切换，经常会使工作流程碎片化并分散开发者的注意力，最终会增加内部开发循环的停机时间成本。
开发者面临的最大挑战之一是重复性手动任务的负担以及工作流程中的低效率。手动配置环境或更新依赖项会降低开发者的速度，并阻止他们专注于解决实际问题。此外，低效的反馈循环非常令人沮丧。当开发者卡在等待测试或部署的反馈时，它会打破他们的流程并扼杀势头。这些延误会损害生产力，说实话，还会损害士气。
容器化本应提高开发者生产力——在某些方面，它确实做到了——但你确实需要整合（和管理）合适的工具，以使你的开发者保持在内部循环中。但即便如此，增加的系统复杂性也会增加技术债务。
例如，对于在本地进行小修改的开发者来说，该周期通常需要四到五分钟。如果一切顺利，他们将继续执行下一个任务。如果不是，他们会继续工作，同时问题仍然很新鲜。并且，假设开发者每天工作六个小时，那么开发者可以完成大约 70 次迭代。
从战略上讲，这种程度的生产力可以解决技术债务。但是，请考虑开发生命周期中的所有非编码任务：计划、任务分配、代码审查、状态更新、CI/CD 管理、性能监控、事件响应、回顾等等。虽然这些活动是必要的，但它们会占用核心编码循环的时间。我们无法消除它们，但很明显，当前的方法并不理想。
因此，在一个干扰和需要在各种工具之间切换（导致精神疲劳和效率降低）的时代，工程领导者很难在资源有限的情况下简化工作流程并提高开发速度，因此，倾向于 DevProd 是解决其组织面临的挑战的当务之急。
通过投资 DevProd，工程领导者不仅在优化工作流程，而且还在投资其软件的基础，并重新获得通过简化内部开发循环流程而损失的速度。统一的解决方案可以显着帮助优化这一点。
容器化非常适合构建和架构应用程序的现代云原生方式。容器使公司能够扩展并为跨不同环境的大量用户提供服务，提供一致性和可移植性，确保应用程序可靠运行，而无需考虑底层基础设施。但对于运营团队来说，这种好处却给开发人员带来了代价——可怕的“容器税”。
对无缝云原生开发的渴望，常常与管理复杂容器配置、依赖项和网络的无差别的繁重工作相冲突。容器在根本上改变了部署和生产的同时，也常常给开发工作流程带来了显著的复杂性。因此，为容器化环境进行开发变得更加困难，而不是更容易。
容器通常会扰乱内部开发循环，而不是简化它。开发人员发现自己需要与 Dockerfiles、Kubernetes 清单以及其他大量特定于容器的工具作斗争，从而使他们无法专注于编写代码和构建功能的核心任务。调试变得更具挑战性，迫使开发人员浏览容器日志并理解复杂的网络交互。而启动开发环境本身也可能变成一个复杂的编排过程，从而减慢迭代周期并阻碍快速实验。
许多工具简化了基于容器的开发。Docker 使容器更易于访问，而 Kubernetes 提供了用于编排容器部署的解决方案。但是，这些工具虽然本身很有价值，但并未完全解决核心挑战：在容器化世界中保留开发人员的内部循环。
这是因为它们通常会增加抽象层，这些抽象层虽然对生产有用，但会给试图快速有效地迭代的开发人员带来摩擦。轻松进行基于容器的开发的承诺常常未能兑现，使开发人员在复杂的容器生态系统中挣扎。
然而，开发人员喜欢本地设置，即使在使用容器化应用程序时也是如此，无论这些环境是本地的还是远程的，因为本地开发的熟悉性和速度允许快速迭代和更快的反馈循环。但是，将本地更改与远程容器化环境集成可能非常具有挑战性，并且可能会减慢开发过程。
开发人员不应该为了保持工作效率而成为容器专家。Blackbird 最近与 Telepresence 集成，为基于容器的开发提供了一种新方法。它使开发人员可以专注于他们最擅长的事情（编写代码），同时抽象出容器管理的复杂性。通过提供专用的、托管的、类似生产的开发环境，Blackbird 使开发人员能够重塑他们的内部循环，使他们能够快速迭代、彻底测试并构建出色的软件，即使在容器化的世界中也是如此。借助 Telepresence，开发人员仍然可以选择在需要时连接到实时远程集群，同时保持在舒适的本地机器上。
希望改进 DevProd 的工程领导者需要首先倾听开发人员的意见。了解他们在哪里遇到困难，并投资于解决这些特定痛点的解决方案。如果您真的想改进 DevProd，请尝试了解简化开发团队的反馈循环如何产生立竿见影的效果。开发人员讨厌等待，因此您可以采取任何措施来加快流程（无论是自动化任务还是改进测试环境）都会提高生产力和士气。
让他们留在内部开发循环中，在那里他们可以做到最好（编码）。并且不要忽视 AI。正如我在 Ambassador 2025 Predictions 中指出的那样，AI 对于自动化重复性工作并为开发人员提供更多带宽来专注于高价值任务至关重要。
AI 已经成为解决手动工作的一项变革性技术。人工智能驱动的解决方案可以自动化配置管理等繁琐的任务，让开发人员专注于工作中富有创造性和复杂性的部分。获得正确的工具可以为 API 开发创建无缝的工作流程，这具有令人难以置信的影响。
您需要寻找能够帮助您加速反馈周期并使开发人员更容易保持流畅状态的技术。无论是用于测试的临时环境还是简化的 AI 驱动的 API 工具，这些技术都可以消除摩擦，让开发人员做他们最擅长的事情。
一切都始于同理心。领导者需要深入了解他们的团队正在经历什么——什么让他们感到沮丧，什么减慢了他们的速度——并努力消除这些障碍。创建一个欢迎反馈和鼓励实验的文化至关重要。当你使用合适的工具赋能开发者并培养协作环境时，开发者生产力自然随之而来。