早上起来看到一封邮件，是我之前订阅的一个issue的提醒邮件，VSCode发布了一个远程开发套件，套件支持SSH、Containers、WSL。什么意思呢？就是可以把远程主机环境、Docker环境以及WSL环境当成本地环境在VSCode里开发。在VSCode的Blog里有简单的介绍，文档里有更详细的说明。

个人认为这个插件可以说是一个划时代的产品了。可能有点夸张，但至少是一个非常大的进步。为什么这么说？我们考虑一下传统远程开发的过程，通常是把文件同步到本地，在本地做Linting，在编辑器中对本地文件的修改实时传给远程。远程调试通常是远程调试器监听一个端口，本地IDE去访问。看似完美的方案实则有很多问题：

• 同步。同步是个看似简单实则非常复杂的问题。主要有以下几个核心问题：
  • 用什么协议？目前大多数IDE都基于SFTP，在大量零散小文件时该协议是非常慢的。但这一问题比较容易解决，可以使用rsync。而且大量零散小文件这种场景并不经常出现。
  • 如何实时监测远程、本地的文件变化？例如git pull后的同步问题。rsync虽然可以做增量同步，但要做监测还需要其他方案。而且一定要双向通信，否则很难做到实时性。
  • 如何解决由文件系统的差异性带来的问题？很显然NTFS与ext的权限信息并不兼容。对文件名的规范、对文件的相关特性（例如软链接）也不同。
• 由于环境不同带来的各种问题。这种问题可以说是层出不穷，除了上面所说的文件系统的问题，还有例如：环境变量设置；对远程库或程序的依赖（要不要同步？能不能同步？如果不同步Linting和调试怎么做？）；调试器不支持远程调试怎么办（虽然很少见）等等。

因此，把远程代码同步到本地来开发就像是雇人往屎山铲屎，你成功地把工作安排好了就不去碰它了当然没问题，但万一哪天有了点变化多了个地方要去铲，你可能就没办法了，毕竟你雇的人可能只能从一个地方铲，不然就要996.ICU了。

正确的做法当然是搞个通用的下水道工程，建个化粪池/处理厂。VSCode的这个远程开发套件就是这个思路，把本地和远程做一个桥梁，让所有的插件都在远程跑，结果回传，这样就彻底解决了这些问题。

当然，你这个下水道工程一定要建得好，不能老堵住。在我们的问题中，其实就是远程开发的性能问题。远程开发一定会损失一些性能，但这一损失能否维持在可以接受的范围内，就很关键了。

这样才是真正的远程开发啊！

PS: 这一套件还在insider过程中，个人打算等正式发布后使用。这下JetBrains有压力了。