前言
大概两年前，vscode推出了以SSH为基础的远程开发插件，当时还只是略作了解，然后拿来作为远程文本编辑的一个备选项。相当于是ssh环境下vim和emcas的一个替代品。作为GUI基础的文本编辑器，在访问未经配置远程环境下，相比使用全默认配置的vim还是要更好用一点，不过也就仅限于此了。
最近翻出来研究的主要原因，是自己的办公电脑配置慢慢跟不上开发需要。虽然4c16g的配置不算低，不过办公机需要开启大量的网页窗口、各类文档、IM软件等等，再加上IDE和大量依赖服务，而且本身所处的开发环境还需要运行额外的监控软件、防病毒软件等等，实际在开发过程中和代码编辑时还是能明显感受到拖慢的。测试一个完整的java项目编译，server端2分钟可以跑完，本地要跑上十几分钟，确实浪费了不少生命。于是一不做二不休，捣腾一下全给搬到server上，通过远程访问方式进行开发。
总结一下的话，远程开发带来的好处大概有这么几个
- 更可控的机器配置，云端虚拟机可以比较方便的做在线扩容。目前我使用的配置是8c32g，如果有需要完全可以扩到32c256g甚至更高。
- 便利的环境快照。基于虚拟机的开发环境，折腾前先做个快照，发现什么问题可以随时回退。或者机器更换，基于快照恢复也很方便。
- 纯原生的linux环境。没啥好说的，可以完整使用linux的开发生态。使用docker镜像啥的也比较方便
- 上下文环境保持。因为server端基本可以一直挂着不用关，不用烦恼每次重启后又要打开一大堆调试窗口或者是启动一堆背景服务。
另外还有一些可以算作远程开发的优势，不过在我的使用场景下不涉及的
- 对客户端性能要求较低，具有一定移动开发友好度。比如在阿里云上申请台高配server，然后本地使用mba或者surface开发，也基本不会受限于cpu或内存等硬件桎梏。
- 低成本的多设备切换。在公司开发到一半了，出差或回家了，用笔记本远程连上就可以继续工作。当然这点要看具体的网络环境了。
至于缺点也有一些，不过我觉得核心就是一条，就是vscode作为一个主打文本编辑器的轻量级开发环境，能否满足开发效率上的需求。
我个人感觉还是有点难度，当然其中也有一些使用习惯上的问题。比如对于版本管理，我个人更习惯intellij中提供的version control界面。基于命令行的tig或是vscode 的插件git lens，个人习惯上还是觉得差一点。
另外对于java项目来说，idea的代码补全（code complete）还是要比vscode更好一点。虽然现在新一代的基于AI模型的代码补全工具在很多时候确实也非常好用，不过短期内感觉还很难取代传统基于语言模型的代码补全。当然最致命的一点是，由于java ee项目的技术栈深度问题，诸如maven、spring boot、junit、lombok等等，idea已经提供了很完备的插件生态来支持开发，而vscode在这方面则多还处于起步阶段。
总体而言，给人的感觉是，在使用IDE时，通常开发者不需要对其背后的运作原理有太深入的理解，只需要专注在自己的代码上就好了。而基于vscode的开发环境，则需要开发者对代码的编译、调试、打包等流程都需要有一定了解才能顺利进行。
如果上面说的这些都不成问题，那么搭建一个server端的开发环境还是非常实用的。
环境搭建
前置准备
这里要准备的东西倒不是整个开发环境必备的，倒不如说是作为开发环境，我个人习惯会准备的一些开发工具。
zsh&oh my zsh
习惯使用zsh，自然是第一时间会装上
tmux
基本是server环境下必装的，用于会话管理和终端窗口管理，也是减轻vscode本身的terminal在窗口管理上功能孱弱带来的影响。
docker
pet
因为windows端我没有用类似dash这样的工具管理命令行snippet，因此选择在linux环境装了pet用来做日常命令的收集。
tig
虽然vscode本身也有git插件，不过纯粹的命令行交互式的git工具在很多时候还是很方便的。
Ncat
比较通用的网络工具，在远程环境下我拿来作为一个比较简单粗暴的转发工具
Ant、maven、gradle、java、gcc、python等开发工具
说实话，如果有人能把这些开发环境统统装好打成镜像，我觉得还挺有用的。不过就算自己准备也不算太费事吧，linux环境下通过包管理工具通常都可以很便利的装好。（我使用的server环境是rhel7.4，因此使用的是yum进行包管理）。
vscode remote安装
本身remote插件的安装其实很简单，在vscode中打开extension然后搜索Remote SSH就能装上。需要额外一提的是，本身这个插件是作用于本地的vscode的。对于server端而言，还需要单独安装vscode-server。当然如果是处于互联网环境的话，那么第一次使用vscode连接到远程服务器的时候，就会自动去下载server端安装包。
不过如果你的server是处于非互联网环境下，那么注意这个安装过程虽然不能顺利进行，但是可以通过提前下载部署server包来跳过，具体可以参考这个帖子。**另外需要注意的是，vscode-server版本是要与vscode匹配的，因此如果vscode更新过了，那么也需要注意更新vscode-server**。
除此之外，基于remote模式，vscode只有界面渲染等与UI相关的部分是在客户端执行的，编辑器内的计算部分是在服务端完成。因此，想要使用vscode的插件，需要在server端安装才能正常使用。
除了基础的编辑、保存等功能外，remote模式提供了一个非常实用的功能就是端口映射。这是由于，因为编辑的代码都是实际存储在server端，编译和调试自然是在server端进行。那么比如我在开发一个前端项目时，写完代码想在界面上调试看看效果，那么自然是要npm start把网站跑起来。可是此时网站是启动在server上，虽然应用会提示说请通过localhost:xxxx来访问，但实际在本地自然是访问不到的。remote插件提供的端口映射功能，就是通过侦测远程端口的开启情况，将本地对应的端口映射到远程端口上，来达到本地访问远端服务，实际体验上就和在本地调试一样。
另外就是我在上面提到的装的ncat。这是因为某些代码需要访问本地客户端的一些服务，距离来说，由于某些原因，我没有在server端安装mysql数据库，此时server端访问本地的mysql就会访问不到。于是我干脆通过ncat --sh-exec "ncat <ip> <port>" -l <port> --keep-open把server上访问mysql的请求转发到本地。这当然不是必须的，不过在过渡期懒得折腾的时候倒也能省不少事。
IDEA&Rsync
虽然理论上采用这种方式，就可以把代码全部搬到server端进行开发。不过正如上面我提到的，使用vscode进行开发，在java ee这种特定场合下，效率上还是不如使用ide来的更方便快捷。于是我想到一个折中妥协的法子，就是在本地用ide开发后，将代码同步到服务端进行编译调试。实际体验中，采用rsync进行同步，其效率还是很高的。
对于单纯的代码同步，rsync命令如下
rsync -avz --filter=':- .gitignore' --delete -e "<ssh_path>" -r <source_dir> <user>@<server_id>:<target_dir>
除了第一次代码的全量同步以外，rsync在后续的同步中会自行进行增量对比，整体效率还是相当不错的。使用.gitignore文件则是把编译、构建过程中不必要的文件排除掉，某种程度上也能加快同步效率。
后记
这通折腾我大概在3月中旬的时候折腾完毕，把整套开发环境顺利搬到了服务器上，也顺利用了近一个月。
意料之外的是，想不到就在我折腾完没过两周，jetbrains就发布了projector产品，同样是通过远程渲染的方案，将基于swing的IDE工具搬到server上，而本地只需要通过浏览器或瘦客户端来访问。
可能未来的趋势，就是IDE慢慢云端化吧。我个人倒是还挺待见这种趋势的，有空的话再折腾一下部署projector，若是可以把idea也搬到服务器上，本地开发就可以彻底成为过去式了。