关键在于找到本地开发速度和容器优势之间的平衡，而使用合适的工具和实践，这是可以实现的。
译自 Optimize Your 'Inner Dev Loop' to Increase Developer Velocity，作者 Matt Voget。
就像每个流行文化都有一个辛普森一家笑话一样，科技界的一切都有一个 XKCD 漫画。一个很好的例子是 “编译,”，来自 2007 年。
图 1
十七年后，编译已经有点不受欢迎了。但我们都知道这张漫画现在会说什么：“我的代码正在容器化。”
容器化在扩展开发方面发挥了重要作用。它允许开发人员在开发的不同阶段以及从本地机器到生产服务器创建一致的环境。
这种一致性消除了古老的“在我的机器上可以运行”问题，并显著减少了与配置相关的问题。
但它也带来了新的问题。容器构建和注册表上传对工程师来说纯粹是停机时间。
容器化可能很慢，这会影响生产力。这种税收通常用于运行和测试代码，然后在代码发生更改时再次支付。你可以看到由此展开的问题。
情况并非总是如此。在没有容器的情况下，传统的开发循环更快，允许更高的速度和更多的迭代。
我们能否在不牺牲容器优势的情况下恢复这种速度？可以。
这里的问题在于“内部开发循环”。内部开发循环 是开发人员在本地工作于功能或错误修复时执行的一系列活动。它通常包括：
- 编写或修改代码
- 构建应用程序
- 运行和测试更改
- 必要时调试
- 提交代码
这个循环在一天中重复进行，其效率极大地影响了开发人员的生产力。这个循环越快越流畅，开发人员可以进行的迭代次数就越多，从而更快地解决问题和开发功能。
相比之下，“外部开发循环”涵盖了更广泛的开发生命周期，包括：
- 规划和任务分配
- 代码审查和协作
- 持续集成和部署
- 暂存和生产发布
- 监控和反馈收集
容器化的优势通过确保环境一致性和简化部署而累积到外部开发循环中。但它给内部开发循环带来了摩擦。构建容器并等待它们启动所花费的时间会降低开发人员高效编码所需的迭代速度。
在容器化之前，内部开发循环可能看起来像这样：
因此，在传统的内部开发循环中，我们每次开发迭代只需 5 分多钟，只有 10 秒的“税收”停机时间。回顾容器化版本，这延长到了 9 分多钟，其中近一半是“税收”。
如果开发人员每天编码 6 个小时，我们从容器化迁移到容器化后，迭代次数从 70 次减少到 40 次。在为期两周的冲刺中，这将损失 300 个循环。
因此，优化容器化环境中的内部开发循环对于保持高开发速度至关重要。
在容器化环境中简化内部开发循环是夺回失去速度的关键。我们必须找到方法来最大限度地减少容器化和部署带来的“税收”，同时保留容器提供的一致性和可移植性优势。现代工具和实践在这里发挥作用。
一种越来越流行的方法是本地到远程开发。这种方法允许开发人员在本地运行代码，同时无缝连接到远程 Kubernetes 集群。像 Ambassador 的 Telepresence 这样的工具使开发人员能够像本地机器是远程集群的一部分一样进行编码。
这个想法很简单但很强大：开发人员无需为每次代码更改构建和部署容器，而是可以在本地运行一个正在开发的服务，并使其实时与远程集群中的其他服务交互。这种方法提供了几个优势：
- 更快的反馈循环： 开发人员可以立即看到其更改的影响，而无需等待其完整应用程序容器化和部署。
- 熟悉的本地开发： 工程师可以使用他们喜欢的工具和 IDE 来保持生产力。
- 访问远程资源： 开发人员可以像访问本地资源一样与远程集群中的数据库、微服务和其他资源进行交互。
- 减少资源使用： 需要更少的远程开发环境，这可能导致成本节省。
- 协作开发： 由于个人拦截等功能，团队可以在同一个集群上同时工作，而不会互相干扰。
采用这些工具和实践可以显着减少内部开发循环的“税收”。让我们用这种优化方法重新审视我们之前的示例：
在这种优化方案中，我们将迭代时间缩短到大约 6 分钟，只有大约 30 秒的停机时间税。这意味着在 6 小时的编码时间内大约可以进行 60 次迭代——这比容器化版本有了实质性的改进，并且更接近我们最初的预容器速度。如上所示，使用本地测试，开发人员循环比传统循环略长，但仍然比常规容器循环快得多，并且它包含容器化的优势。双赢！
目标不是放弃容器——它们在扩展和生产方面的优势太宝贵了。相反，混合方法可以将本地开发的速度与容器化环境的一致性和可靠性相结合。
通过专注于优化内部开发循环，我们可以帮助开发人员恢复他们失去的速度，从而导致更多迭代、更快的功能开发，以及最终更快地获得更好的软件。关键是找到本地开发速度与容器化优势之间的平衡——有了合适的工具和实践，这种平衡是可以实现的。
最终，您的开发过程可以如此流畅，以至于您甚至没有时间在容器化时查看 XKCD。