不想换掉 Atom

正式开始将编程任务变成主要工作任务是 2015 年，在那之前写代码都是用 vim 或者 BCompare 随便改改就能胜任的工作。

当时选型 IDE 是个比较困难的活，依靠推荐都是一个比一个有局限性。

比较靠谱的推荐：

• 有不少推荐 Sublime 的，当然是破解版，麻烦先不说，很多人只推荐 2 版本， Bug 一大堆没事就崩，3 版本很多人都不推荐。怀疑他们以前是写 Perl 的；
• 写 JAVA 的都推荐 Eclipse，其不友好性太吓人，我也是一直都反感 JAVA；
• 最硬核的推荐用 Source Insight ，这个虽然很强大，至今为止依旧站在霸主席位，然而我驾驭不了函数跟踪啊。

还有些不靠谱的：

• 那种大概这辈子写过不超过 20 行代码的人，推荐微软的 Visual 系（Visual C、Visual Basic、Visual Foxpro）；
• 很多一行代码都没写过的也来凑热闹，Office Frontpage 和 Adobe Dreamweaver 都祭出来了；

最终求人不如求己，还不如去大平台上看看都推荐什么编辑器。很巧的是 GitHub 直接丢了一个 Atom 胡在我脸上，还是 Beta 阶段。

好用！

解决我的需求

最初的需求其实挺简单：能编辑文件就行了！！！

当时没对这些编辑器抱什么太大指望。自 2014 年某事件后，便开始感受到，中国软件行业平均水平就那德行，代码质量就那尿性，代码规范如海市蜃楼，软件测试可有可无，打包部署若有可无。整个行业的状态是密集劳动型行业，重产量而轻质量，重噱头而轻需求，重日活而轻用户。就那德行。

所以没指望一个农民的耙犁自带滚轮。

GitHub 的这个耙犁还真自带滚轮！

首先我的开发环境是 Windows 7 的，而目标开发平台是 Linux，主要语言是 PHP 和 JS，所以我大部分时间是在本地写好文件，之后依靠 SFTP 同步过去。其次我的编辑环境并不是开发测试环境（这个设计是为了防止多人开发碰到 SB 覆盖或删除你的代码，这种 SB 还挺多的），我的 Linux 编辑环境一般都是个本地虚拟机或者虚拟环境。本来是想着每次靠 BCompare 自己手动 merge ，但是这工作量是 毫无意义的。很多人更倾向于冒这个险：「什么事都没有」或者「代码被同事删掉，一天或一个星期的活白干」。

Atom 的 插件 Remote-FTP 能直接连接到 SFTP 服务器，并且展开一个非常清晰的树形结构，和本地编辑区别不大。直接减轻了我每次手动复制文件的痛苦。

除此之外，其自带的很多功能，比如 Markdown 预览，直到现在我依旧使用这个功能用来写 WordPress

很多功能也可以用插件来实现，比如：

• atom-beautify 和 linter：检查和自动规范代码风格
• color-picker：颜色快速选择

嗯？仔细想想也没装几个插件。我甚至连 minimap 和 emmet 都禁用了。

Atom 的反对声

自我开始使用 Atom 之后，反对的吐沫星子就能游泳。

最多的反对意见是 Atom 的性能问题。这个是比较明显的问题。除了 Electron 自身的问题之外，Atom 监控工作目录下的文件变化是主要原因。像 PHP 还好，目录层级下不会有 太多 的文件。但像 node 这样的，工作目录下文件复杂度超出 Windows 导致资源管理器都把持不住乃家常便饭，Atom 打开这样的目录一般都必死无疑。我因为是使用 SFTP 的，所以本地工作目录永远只有自己需要编辑的文件，所以一直遇不到这样的问题。但是假如有同事直接拿优盘考个项目过来，恶，光是复制项目文件就能用掉半个小时，更别说编辑了。

而且由于一直用 SFTP ，所以我的工作目录既不是开发测试环境，也不是 Git 仓库，所以提交代码还是需要使用 BCompare 这些工具来同步，当然好处就是对个人而言，协同办公既轻松又容易，自己再不担心覆盖掉别人的代码。

假如有人在我的电脑上乱改代码又不生效时，就是对人不对事了。

当然用 SFTP 也有一个大缺陷，就是 ESLint 完全用不了。

Atom 正在死亡

接触并使用 Atom 时，VSCode 还裹着尿布呢。

谁成想 GitHub 竟然会有一天被收购，还是被微软收购。

当时很多人担心基于 Electron 的软件将失去未来，毕竟微软的口碑虽然已经转好，但是微软毕竟是微软。后来分析微软的 VSCode 也是基于 Electron 的。

Electron 不会死，但是 Atom 就不一定了。

微软虽说 GitHub 会继续独立。但是群众是用脚投票的。最明显的就是大量的 Atom 插件开发者叛逃。我插件用的不多，然而第一个大户 atom-beautify 就跑去做 unibeautify 去了，嘴上生成今后会同时支持 VSCode 和 Atom，然而 3 年过去了。你知道在 Atom 上 atom-beautify 是没有竞品的，而在 VSCode 上 Beautify 类的插件能淹死人，这三年过去了 unibeautify-vscode 的 star 数只有 74，而 Atom-beautify 的 star 是 1.4k。

我在全新环境下的 Atom 上配置下 atom-beautify 和 linter 也就几分钟的事情，在 VSCode 上一筹莫展，PHP该用哪个？JS用哪个？HTML用哪个？CSS用哪个？Shell用哪个？Markdown用哪个？JSON用哪个？YAML又用哪个？

Atom 自身开发团队也很不给力，2018 年因为一个更新引入的一些 Bug 到现在也没修复，issue 一直有人来问相同的问题，但是没人维护。（比如这个 https://github.com/atom/markdown-preview/issues/552）

然而并不想使用 VSCode

其实也有打算换 VSCode 了，一方面微软近些年来口碑逐渐转好，和谷歌共同形成此消彼长的态势。另一方面 VSCode 的占有率也比较恐怖。

昨天在本机装了一下，结果感觉很不好。

插件问题甚是头疼，随便搜了一下 SFTP 插件，这结果也太多了。

随便试了一下为首推荐的，用起来真难受。

你说我双击打开一个文件是为了看着玩的？

说真的其实另一个考虑 VSCode 的原因是因为 ShachikuChanIDE 这个插件，然而我才知道这是 VS 插件，不是 VSC 插件。（好感度-1）

有人说 VSCode 生态好，我觉得大概是对生态有什么误会吧？兄台你有没有用过 Android 2.0 时代的国产机？各种五花八门的手机应用市场遍地开花，质量低劣的 APP 堪比牛皮癣，那玩意不叫生态好，那叫生态大。

我估计为 VSCode 背书的人其实有不少是冲着其自带的 Git 管理去的（当然 Atom 也自带 Git 管理，然而在复杂目录下，比如代码结构比较狗屎，一般狗屎就行，Atom 就会卡死，所以这也是没人愿意用 Atom 的理由之一）。

已经有很多人在到处宣扬：VSCode，真香。

我觉得这些人吃什么都是香的。

恶习难改

换掉一个用了 4 年的 IDE 真心困难。

就像……

算了，不举例了，这一篇文章得罪的人就够多的了。