为什么 VS Code 是我的主力 IDE

因为工作关系,我有机会接触不同团队的开发者,发现主流的IDE主要分为两类:VS Code和JetBrains系列。当然,对于Mac或iOS开发,XCode则是首选。由于我日常工作中只需要编写一些小型Demo,我逐渐从JetBrains转向了VSCode,后者相对轻量且灵活。

最初,我将VSCode视作一个高级文本编辑器。对于Java、Golang等语言,我感觉使用起来并不是很舒服,因此有一段时间我仍在用JetBrains。然而,在过去的一年中,我注意到VSCode的插件越来越成熟,使用起来也更加顺手。现在,VSCode已经成为我的主力IDE,原因如下:

1. GitHub Copilot Chat

我有几年Java项目的底子,但对其他语言仅限于入门水平,有时还需要编写bash、terraform等脚本。因为在这岗位相对于软件工程师来讲,涉及到的技术问题会更广或庞杂,要做一些 Demo 出来演示一下,或用个专门的技术快速解决专门的问题。

自从我司入股 OpenAI 之后,我这个小员工也尝到了不少甜头,Auzre OpenAI 服务,GitHub Copilot 很快就开通了,前面说的日常写代码或脚本的事情  GitHub Copilot 其实能帮我不少,尤其是我不懂但社区里已经司空见惯的场景。

GitHub Copilot Chat的推出,让我体验到了显著的效率提升。它更新了模型,支持了内联聊天功能,允许我直接在代码中进行交互式修改,而不仅仅是接受编辑器的连续提示。倚靠GitHub Copilot Chat,我扩展了社区的一个类chatgpt 的web应用供自己使用,这个应用是 typescript 编写的,我之前从来没写过typescript,现在我的每天日常工作和生活都离不开这个应用。借助它,我甚至在1小时内完成了使用Python分析客户故障性能日志如果没有它,我可能需要花费几天时间学习pandas、dataframe等Python库。

为什么 VS Code 是我的主力 IDE

而 GitHub Copilot Chat 这个功能在 JetBrains 平台迟迟没有 Public 出来(但也就这几天了),所以我会过去一直依靠 VS Code 的 GitHub Copilot 。

就目前看, JetBrains 的 Copilot Chat 短期还不会支持 inline chat 的能力(如上图的红框内容)。另外现在的 Copilot Chat Agent 扩展短期不会出现在 JetBrains 上,例如通过 @workspace 检索当前工作区更广的范围,而不仅是基于当前打开文件或选中的代码,这样在 Copilot 提供建议时更加精准,再例如自行扩展 agent 到 Copilot 中检索内部代码的向量数据库,打造更适合自己的 AI 结对编程助手。所以需要这些功能的话暂时用 VS Code 吧,我个人觉得现在 VS Code 在大型项目开发也不错。

为什么 VS Code 是我的主力 IDE

2. DevContainer + Remote SSH + 核心小技巧

和第一条的开头一样还是因为我平时需要写一些 Demo, 可能会涉及不同的编程语言、框架。在我的 PC 上搞着搞着环境就容易变得混乱。一乱我就不想再碰这套技术环境了,这个时候我就会想到容器。 在 VS Code 就可以用 DevContainer 来管每个 Workspace 或 Repo 的代码开发环境,这个时候在我的 PC 启 Docker 容器就好了。通过Dockerfile和devcontainer.json配置文件来设置所需的编译和调试工具以及VSCode插件列表。

为什么 VS Code 是我的主力 IDE

这个时候问题又来了,我不想把我的 PC 弄的很卡,放的东西很杂很碎,日常我需要装的软件已经很多了,有些还是比较重的软件。如果我还在本地用 DevContainer ,我本来不高的电脑性能和磁盘空间就很快会被榨干。我作为一个云厂商的员工也不能把所有的东西都放在本地 PC 上,该用 OneDrive 用 OneDrive,该用 GitHub 用 GitHub,该用 Azure 用 Azure。

相信很多人都听说过且用过 VDI, 很多企业为了避免公司内部核心资产流出公司,会给员工提供 VDI 的环境,通过公司内部的安全网络通道去访问。另一方面,VDI 环境运行在虚拟化资源(私有云、公有云都有)上,只有数据在,机器坏了漂到另外的机器上就好了,这样数据可以做统一备份,容错性高,用户侧的 PC 电脑不用高配甚至用些低端的瘦客户端就行,成本也能降一降。Azure 也有类似的产品方案。公司也给我们员工配了 VDI 的环境,但我很少用。因为对我来讲有更好的选择,毕竟环境连接有复杂性,VDI 内部还有一些限制,不够灵活。我平时最多拿它刷刷内部系统、报表什么的。

所以我把方向转向了 Azure Spot VM, 我司会给员工一笔 Azure 的经费,我日常还需要做一些其它的测试,时不时还会收到邮件警告钱用超了。所以我也只能尽量用便宜一点的,Spot VM 的价格很低,很多机器都是两三折,最近很火 GPU 卡的 Spot 价格也很低,所以平时我自己用的时候都尽量选  Spot 机器,再找个 AMD 型号的,用的时候再开,也不用买 RI, 非常适合我拿它来 Remote 的开发环境。 这就有了我前面说的 DevContainer + Remote SSH 的组合,我会把代码都 clone 到这台机器上,然后通过 VSCode SSH 连接这台机器并打开对应的 WorkDir 后, 让 VSCode 加载 devcontainer 目录就可以了。虽然我的代码是在远程,程序运行时监听端口会自动的 forward 到本地,我测试起来也会很方便。所以这个事情的大体的框架就没啥问题了。

接下来是一些细节的问题,我在 DevContainer 里怎么运行 docker 命令?我的程序也是要做成容器镜像的, 我不想我在 DevContainer 里每次都重新配置一遍 github 的身份,az cli 的身份,包括我的 oh-my-zsh。我不希望在引入一个工具解决了原来的目标问题后,得将就着新的问题或损失原来的体验, 这些东西我也不想写入devcontainer 镜像里,有点丑陋说实话。所以这个时候需要在 devcontainer 启动时要下些功夫。例如:

a. mount 宿主机的 docker相关的目录或文件, 这样在 devcontainer 里也能 build 和推送镜像

b. mount 宿主机的家目录, 把.ssh, .gitconfig, .azure, .oh-my-zsh,.zshrc,.profile 传递到 devcontainer 中,这样就能把相关身份信息和个人喜好配置都传递进去

为什么 VS Code 是我的主力 IDE

我会做一套相对完整的 devcontainer 配置,其中包含了多种编程语言的编译和运行环境,以及相应的VSCode插件。我将这套配置存放在一个Git Repo中,每当我需要启动一个新的Dem或 Repo时,只需拉取这套devcontainer配置即可,极大地简化了我的工作流程。如有额外的个性化需求,我只需加一丢丢脚本到 post-create 的钩子里。

总结来说,VSCode的灵活性和插件生态让它成为了我的首选IDE,特别是结合了GitHub Copilot Chat和DevContainer等功能,它极大地提升了我的开发效率和体验。

以上。

原文始发于微信公众号(IT快餐):为什么 VS Code 是我的主力 IDE

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

文章由极客之音整理,本文链接:https://www.bmabk.com/index.php/post/225453.html

(0)
小半的头像小半

相关推荐

发表回复

登录后才能评论
极客之音——专业性很强的中文编程技术网站,欢迎收藏到浏览器,订阅我们!