我花了十年时间负责开发工具团队。在这段时间里，我见证了Vagrant的兴衰和Docker的引入，以及其他许多构建工具的出现。我记得大多数开发者桌下曾有两台电脑，我帮助他们大规模迁移到Mac笔记本电脑。我还帮助开发了在AWS上自助计算的内部平台。所有这些工具都旨在将生产环境更接近开发环境，并提供本地环境的简单配置和可扩展性。然而，它们都没有完全做到这一点。

自从与 Palantir 交流以来，我与许多不同的开发者体验负责人进行了交谈。结果发现有一些共同的主题。

• 许多开发人员在笔记本电脑上遇到性能不佳的问题。 这可能是由于安全工具配置不当、本地进程过于复杂，以及经常是 Chrome 占用资源过多造成的。
• 大多数公司在 Mac、Linux 和 Windows 之间选择时感到困扰。 在大多数情况下，IT 团队不得不为这三种操作系统提供支持。总有一些工具或库在不同系统上的表现差异很大，导致问题。然后，像 Mac 的 M1 芯片这样的新技术出现，情况变得更加复杂。
• 前端开发人员与 UX 设计师合作困难。 在这个远程工作时代，大多数公司没有很好的设置来帮助设计师和开发人员合作。许多公司仍然依赖截图或短视频来演示新的 UI 组件——这太糟糕了。
• 高性能笔记本电脑价格昂贵。 如果你有一个计算密集型的应用程序，你可能需要为每位开发人员花费 4000 美元，而且每当他们喝醉后把笔记本电脑留在酒吧里时，你还需要再花 4000 美元。

但说实话，这些都比不上这个：

• 大多数工程师并不满意他们的本地开发环境。 说实话：你觉得你的笔记本电脑好用吗？你的笔记本电脑是阻碍了你，还是帮助了你？

如果你非常爱你的笔记本电脑，并且从未因为关闭大多数应用程序来确保Teams会议不卡顿而烦恼，那么这篇博客文章不适合你。请离开吧。

远程开发涉及使用远程机器执行所有构建和测试过程，而您的笔记本电脑仅作为浏览器或轻量级客户端。

不想继续阅读这篇文章？ 您可以直接访问这个 GitHub 仓库，并在 20 分钟内尝试 Coder OSS。如果您想了解更多关于为什么远程开发是更优越的开发环境的信息，请继续阅读。

如果你喜欢这篇帖子，请 👏 ，订阅 ，或在 medium 或 LinkedIn 上关注我，让我知道我走在正确的道路上！

· 远程开发比本地开发好在哪里？
· 在30分钟内启动一个远程开发生态系统
· 远程开发最适合解决哪些问题？

远程开发显著提高了开发人员的生产力

远程开发的核心论点是，通过将开发工作负载转移到远程机器上，你可以比分发新笔记本电脑给开发团队更快地移动、配置和扩展远程机器。如果远程机器针对你的使用场景进行了优化，它可以做到以下几点。

• 提高构建和测试速度: 可以根据每个项目的具体需求对底层虚拟机进行扩展和优化。在我们的实验中，我们将构建速度从9分钟缩短到了2分钟。
• 减少延迟: 通过将远程环境放置在正确的区域，可以显著减少与基础设施或云API的距离。对于在澳大利亚工作的开发人员来说，如果他们基于美国东部的基础设施工作，这可以将多个流程的效率提高10倍。
• 消除耗时的设置步骤: 每个仓库都有可以自动化的设置步骤，当你控制工作空间时，这会变得更加容易。特别是在拥有旧仓库的大组织中，自动化安装一次，就可以节省所有人的时间。
• 多个环境: 在对库进行重大更新时，可以并行启动第二个工作区以应对这种情况。这可以将环境修改保持在可控范围内，使你能够继续针对原始代码库编写代码。

我第一次遇到这种模型是在与一位工程师交流时，他正在远程虚拟机上使用code-server（注意它有57000颗星）。他的主要问题是由于笔记本电脑上安装了太多安全工具，导致他的IDE崩溃，无法检出和构建大型代码库。我感到非常惊讶，但很快意识到这种模式无法扩展。虚拟机成本很高，为每位开发者运行一个或多个环境是不合理的。开发者只需要在工作时间内使用环境，这种使用场景非常适合Kubernetes。

部署远程开发环境为 Kubernetes 的 pod 解决了我的成本和设置问题。我可以控制执行环境、基础镜像和安全实践，并且可以通过随着开发人员开始和结束工作日来增加或减少计算能力，利用成本优势。

如上所示，每个开发者的理念是拥有自己的持久卷，但其底层容器可以是临时的。由于存储成本仅占总计算成本的一小部分，这使得开发者在工作日可以运行非常强大的容器，而公司只需在晚上和周末花费少量的钱。

好的，好吧——我其实并不真的认为它会消失，但并不是因为我有非常有说服力的论据。像 Google 和 Facebook 这样的大型组织多年来一直在使用远程开发模式，但使这种体验变得出色的开源工具直到最近才逐渐跟上。

最合理的反驳理由是，对于那些在互联网不稳定地区工作的开发者来说，远程开发并不理想。虽然这一点目前确实如此，但随着像 Starlink 和 ASTS 这样的努力，我相信我们离实现全球可访问的互联网只有几年的时间了。

第二个最合理的反驳意见是关于 JetBrains 系列 IDE 的远程开发体验。JetBrains 在 2021 年发布了 Gateway 来解决这些问题。不幸的是，JetBrains 的 Gateway 刚开始时体验不佳，我不会推荐它给全职使用 IntelliJ 或 Webstorm 的用户。然而，在过去的一年里，它取得了显著的进步，预计在 1-2 年内，用户会发现它的体验与本地开发相当。

坦白说，主要的犹豫在于不相信基于浏览器的IDE能够被全职开发者接受。它肯定会有延迟、难用、不可靠，或者有什么不愉快的地方吧？

这里就是 CoderOSS 大放异彩的地方。它提供了一种免费的方式来让你自己体验一下开发人员的远程开发体验会是怎样的。亲自尝试一下是最好的方法。

我已经建立了一个易于使用的仓库作为演示路径，展示在Kubernetes上远程运行Visual Studio Code的样子。我选择使用Google的托管Kubernetes服务，因为它们提供了300美元的信用额度，并且GKE Autopilot非常简单易用。

Coder 安装说明:

• 创建一个 Google Cloud 账号，一个项目，并在该项目中创建一个具有 编辑者权限 的 服务账号。
• 叉取我的 仓库，并使用 spacelift.io 或等效工具进行设置
• 设置 GOOGLE_CREDENTIALS 和 TF_VAR_project，使用上面创建的项目 ID
• 运行并应用 Terraform。

整个设置应该花费你不到10分钟的时间，不过如果你是第一次使用Google Cloud，可能需要花费一些更多的时间。

Coder 设置说明:

• 访问负载均衡器的IP地址（Google Cloud / Kubernetes Engine / 服务与Ingress）。
• 创建初始的用户名和密码。
• 转到模板 / Kubernetes / 创建工作区并为工作区命名。
• 三分钟内，你应该看到如下内容：

• 点击 ‘code-server’ 应该会打开一个新的浏览器标签页，在远程系统上运行 VSCode。

不知道你是否也有同感，但当我第一次看到它的实际操作时，真的让我大开眼界。我习惯了使用 Windows 远程桌面或 VNC，而用浏览器作为我的全职 IDE 的想法听起来像是一个噱头。然而，当我真正看到它的实际操作后，我彻底被说服了。

多年来，我领导了一个开发者体验团队，并且作为一名坚定的 DevOps 信仰者（至少是根据《凤凰项目》中描述的 DevOps）来说，虽然优化公司的开发工作空间很重要，但这可能不是你最重要的问题。如果你遇到以下列出的问题之一是你的主要问题，那么远程开发值得探索。

适合远程开发的问题

• 长时间的构建、执行或测试时间 (>5分钟) 通常受限于计算、内存、磁盘、网络、延迟或甚至操作系统。所有这些都可以通过远程开发模型进行调整，并且可以根据具体情况来调整。
• 修补旧代码 如果工程师需要设置本地工作站以与历史版本、遗留代码或很少使用的代码库一起工作，可能会非常耗时。如果将环境封装在容器中，设置将不再手动，并且仅受限于容器的启动时间。此外，像 Coder 这样的工具支持为每位开发人员启动多个环境，使他们能够为紧急修复启动专用环境而不干扰当前工作。
• 保护源代码（即，物理隔离） 在处理法规（例如，ITAR）、金融系统或安全关键系统时是必要的。许多这些组织力求完全物理隔离以防止源代码泄露。维护物理隔离的开发笔记本电脑比维护远程开发容器要困难得多。

适合远程开发的开发类型

• 前端开发 可以因为计算/内存容量的增加而大幅提升开发效率，而 VSCode（最流行的前端开发 IDE）与远程开发配合得非常好，这得益于 coder/code-server 及其通过 SSH 进行远程后端开发 的能力。此外，Coder 支持远程开发 URL，这使得开发人员可以与设计师在实际产品上进行协作，而不是通过 GitHub PR 中的截图。
• 内核或任何跨操作系统开发 可以得到改进，因为你正在运行的目标操作系统上的 IDE。Coder 的开源模型并不特定于 Kubernetes，你也可以提供 VM。
• 空气隔离网络 是一个很好的应用场景，因为你不必花费太多时间来处理工作站。位于网络之外的工程团队可以创建一个基础镜像，然后将其导入内部网络。这对于银行、医疗保健或军事应用场景非常有用。

远程开发正迅速成为本地开发的一种替代方案，而 Kubernetes 模型似乎是这种替代方案中最吸引人的一种。一个工程团队可以轻松地将其容器的内存容量翻倍，但将笔记本电脑的内存翻倍则过于昂贵。无论你尝试如何优化代码，最终你常常会受制于 Chrome 或占用资源的安全工具。

Kubernetes 远程开发模型鼓励对开发需求进行全面封装，这对于需要处理历史版本或遗留代码的公司来说尤其有利。Kubernetes 模型还支持水平和垂直扩展，防止开发人员因“性能”问题而效率低下。最后，你的财务团队会感谢你为开发人员配备了更便宜的笔记本电脑。

虽然远程开发长期以来一直是像 Google 和 Facebook 这样的软件巨头的常见做法，但 Coder OSS 已经打开了大门，使任何规模的公司都能轻松访问它。如果你按照我在 repo 中的说明操作，你可能已经在不到 30 分钟的时间内亲自看到了这一点。

希望你喜欢这篇帖子。如果喜欢，请给我点赞、关注或在 LinkedIn 上联系我，让我知道我达到了你的期望。