«

»

Dec 02 2019

不想换掉 Atom

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

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

比较靠谱的推荐:

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


还有些不靠谱的:

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

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

好用!

解决我的需求

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

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

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

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

snap2751

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

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

snap2753

除此之外,其自带的很多功能,比如 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 插件,这结果也太多了。

snap2750

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

snap2754

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

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

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

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

已经有很多人在到处宣扬:VSCode,真香。

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

恶习难改

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

就像……

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

14 comments

Skip to comment form

  1. 萃香西瓜

    我问了身边的几个js同学,他们大部分用vscode,少部分用sublime。至于为什么用vscode,主要原因是“同事都用这个”,以及“内置插件丰富”

    不过我觉得独立开发和团队开发的情景应该是不一样的,不能混为一谈

    IDE是生产工具,等到他妨碍生产效率的时候再考虑换吧

    1. 石樱灯笼

      目前不认为中国有团队开发这个概念。
      我当时转型做开发是给自己准备了一套很容易适用于各个场景的工具集,我以为多数开发者都会准备这么一套,结果参加工作后发现大部分人入职第一个星期都是睁眼瞎状态。
      一方面公司项目工具都是坑坑洼洼,另一方面多数开发者都是将自己局限在一个极为狭小的范围内寻求安逸。不过根据结论来看,这种做法完全没有问题,不能对中国IT行业期望过高。
      然而事实上这就像是热锅里的螃蟹,谁在上面就掐断谁的腿。在只有 Windows 的公司用 Mac 或是用 Linux 都是会被排挤的。不仅是技术视野,在人际关系上IT行业也和其他行业没有什么区别。

  2. 萃香西瓜

    另外看到SFTP,我在想是不是可以用基于SSH的方法去实现远程编辑,比如:
    https://code.visualstudio.com/docs/remote/ssh?spm=ata.13261165.0.0.33ac63e8xtO2SX

    1. 石樱灯笼

      感觉这像是登录到另一台机器上操作,与其说是 SSH ,到更像基于 SSL 的远程桌面,只不过是针对文件系统的。
      这个场景应该是瘦终端吧。SSL 的性能并不高,操作速度太猛的话很容易就出错。在我看来瘦终端这种场景放在软件开发上更像是一个笑话。
      当然我个人认为或许某一天真的会普及,只不过是基于行业的倒退而实现的。

  3. zmmio

    像我这种半吊子非常业余选手,Notepad++就能胜任我的需求了.

  4. 大胸弟

    我 正经开发PhpStorm ,临时救火 Sublime Text 3

  5. 大致

    还是建议转VSCode。我用来玩php和GNU C感觉都可以。
    atom的插件挑环境,我在家里debug用zwamp就没事,xampp就慢得要死。而且是更新某个版本之后才有的问题。
    我还用过NetBeans,各方面都很像Eclipse。
    用Sublime还不如用Notepad++

    当然在单位干活是VisualStudio和基于Eclipse的一款IDE,都是花钱的。基于Eclipse的那个非常难用,Make Clean总处理不干净,还得自己写bat删。

    1. 石樱灯笼

      atom插件和vsc插件从根源上都是一样的,还是看写插件的人是怎么写的了。
      我从不在windows上写服务端,所以zwamp xampp 什么的我从来不接触。
      除了编辑功能,像make或git我都是不在ide中运行的,信不过。

  6. 心灵博客

    当年也在强烈的安利下使用了半次atom就卸载了,node的东西真心喜欢不上。

    1. 石樱灯笼

      现在多数PC应用都是node+webkit套层皮,VSC不也是么。

  7. 小宝

    抛开 Atom 和 VSCode 不谈,不得不说互联网行业的工程师一直是被行业巨头牵着鼻子走的。
    之前读过一些分析,有人说到不同产品之间的技术差异终究会抹平,最终上升到的是人文层面的企业博弈和标准制订环节。
    每次那些行业巨头发布什么新品以所谓“革命性的”噱头赚钱,对终端用户(消费者)来说不就是掏多点钱享受更先进对科技而已;
    但很多人不知道新产品发布的背后意味着有多少工程师面临失业。就比如现在我们学校的 Win32 编程课已经全部取消了。

    1. 石樱灯笼

      我倒觉得你说的这个「被行业巨头牵着鼻子走」的状况,在任何产业都说得通。
      然而你举的这个 Win32 的例子反倒不太贴切。
      Win32 编程是巨坑,世界上多少个大企业都没搞定,做出来的东西都巨丑,要不是诺基亚当年力挺了一下Qt,我估计桌面端还在9x时代打转悠呢。
      桌面编程的困难是巨大的,现在没有哪个巨头敢摸,也就意味着完全没有工作机会。这个课取消就取消吧。

      1. 小宝

        「被行业巨头牵着鼻子走」是底层建设者们的无奈。
        另外,其实这个课早在我入学几年前就已连同 Windows 操作系统原理课程一起取消了。

        1. 石樱灯笼

          Windows 操作系统原理能讲啥,一个闭源系统,外侧技术肯定过时了,你看现在不也没有 iOS 操作系统原理什么的么。不过正常来讲 操作系统原理 这个课应该还有,或者改名叫别的了。我以前买过类似的书,讲的就是深入层次的系统编程。现在再做系统编程都是针对 Linux 的内核开发,国内能做的人太少,难度不低,大坑太多,像国内这种行业风气根本赚不到钱,我一哥们做了多少年了最后做得饭碗都丢了。(公司不能没有他,但是公司可以倒闭啊)

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据