我为什么删除了我的 IDE；以及它如何让我的生活变得更好

我删除 IDE 的 5 个原因

大约三年前，我彻底改变了自己写代码的方式。我发现很多情况下，我的 IDE 拖慢了我的速度，而不是帮助我工作。于是，我做了一个大胆的决定，彻底删除它。

当然，很多人听到这个消息都会感到震惊，而且绝对不建议所有开发人员都这么做。在这篇文章中，我将分享我最初删除 IDE 的动机，以及在没有它的情况下我是如何继续前进的，以及其他可能考虑这个选项的人。

准备好？

我删除 IDE 的 5 个原因

1.系统性能

我同时使用多种编程语言：服务器使用 Java，部分客户端使用 C++，前端使用 JavaScript+CSS+HTML，以及用于一些自动化任务的 Groovy+Bash。为每种语言运行多个 IDE 需要太多资源（例如 CPU/RAM），这导致我正在开发的程序在运行过程中出现问题。有些 IDE 会不时卡死，而有些则会直接崩溃。所有这些问题都导致编译、链接和发布代码的时间过长。

另外，每次重启电脑都需要很长时间预热，因为它要运行太多IDE。为了避免漫长的等待，我开始让电脑连续几个月处于睡眠模式而不是关机，这导致操作系统随着时间的推移变得越来越慢。

2. 系统可靠性——“巫术”

如上所述，使用 IDE 时，你不得不处理它无缘无故崩溃的情况。我尤其在使用 Eclipse 和 XCode 时遇到过这种情况，但其他 IDE 也遇到过。

有时，程序中的异常会导致 IDE 出现 bug 或意外行为。大多数情况下，clean+build 或 clean+publish 可以解决问题，但有时您必须关闭 IDE，清理其元数据，然后从头开始配置。

例如，有时我无法停止服务器，可能是因为我的代码中存在错误，但是可以合理地期望 IDE 理解我正处于开发过程中，并允许我在出现错误时终止该进程。

3.多种环境

我的日常工作需要在功能构建、代码审查和错误修复之间切换。我希望任务切换操作能够节省时间，并能够并行处理多项任务。使用 IDE 实现这一点则困难得多。原因有二。首先，IDE 占用大量 CPU、RAM 等资源。其次，同一个 IDE 的多个实例可能会相互干扰。

最重要的是，当我在工作期间在分支之间切换时，这种情况经常发生，因为我同时处理功能和错误，所以重新索引代码并为工作做好准备需要很长时间。

4. 在远程服务器上工作

我的工作有时需要在多台远程机器上运行多个服务器，并针对它们进行测试。我不喜欢仅仅为了测试而构建并安装一个包。我更喜欢像使用自己的机器一样使用这些机器，而且不使用 IDE 可以让这项任务变得轻松很多。

不过，使用我最喜欢的文本编辑器（Sublime）来编辑代码比使用 vim 或其他命令行编辑器更舒服。我通过结合使用 rsync、git push/pull、sftp，甚至直接复制粘贴到 vim 来解决这个问题。

5. 可访问性

即使 IDE 已完全配置自定义快捷键，某些操作仍然需要使用鼠标。这样做的问题是，即使只是将手从键盘移到鼠标上进行排序、调整视图大小或将键盘焦点移动到 IDE 的某个部分，也会降低你的速度。这完全取决于个人喜好，但我还是希望尽可能避免这种情况。

关于 IDE 的另一个重要问题是它占用的屏幕空间：一行用于窗口标题，另一行用于菜单，另一行用于工具栏。这还不包括打开文件之间的选项卡切换器。这导致代码本身只能在屏幕的一部分区域显示，操作起来很不方便。

那么，您删除了 IDE — 下一步是什么？

1.了解IDE功能

首先，你需要了解 IDE 的功能：它如何编译代码、如何将代码发布到服务器，以及文件在文件系统中的组织方式。幸运的是，OverOps使用了 Gradle、CMake、Bash 和 Groovy 等标准构建工具，可以直接从命令行运行。

因此，我从命令行运行这些工具，并使用 Bash 命令组合来发布和运行 OverOps。使用 cp、mv、rm 等基本文件操作命令来操作文件，然后使用 less、nohup、kill、ps、htop 等命令来监视和控制程序。就像在生产环境中一样。

2. 构建自己的工具

过一段时间，您将开始意识到哪些命令使用得最多，并且可以开始为它们创建一些别名。

为了我自己的工作，我把这些别名放在 ~/.bashrc 文件中，该文件会在每次 Bash 会话中自动引入。当文件变大，包含更多有价值的别名时，我决定是时候备份它了。我创建了一个新的私有 git 仓库（使用 bitbucket 进行管理），并将文件放在那里。我将仓库克隆到本地目录，并使用source命令从 ~/.bashrc 文件引入它。

这时，我开始真正享受这种无需 IDE 的工作方式。因此，我决定像处理普通代码一样，额外投入一些精力来模块化这个文件。我创建了一个主文件来包含一些较小的文件。每个文件都有一个作业，例如 .gitignoregit.sh包含所有与 git 相关的别名和函数，而.docker 则docker.sh包含一些与 docker 相关的基本命令。此外，还有一些通用文件，其中包含与任何特定程序无关的别名和函数，以及一些与我所负责项目中特定组件相关的文件系列，例如 moduleXXX.sh。

3. 发现你的 IDE 不能做而你能做的事情

这种工作方式的一个有趣之处在于，你可以创建脚本来执行一些你从未想过会成为 IDE 一部分的复杂任务。你可以创建函数来自动执行构建、运行、调用一些内部代码、等待关闭以及最终检查错误代码的过程。所有这些只需一个简单的命令即可完成。当然，你也可以通过创建插件在 IDE 内部实现这一点，但编写插件比仅仅编写一些 Bash 函数要费力得多。

一个很好的例子是我在公司领导的一个主要项目。我们需要将代理移植到 AIX 平台，但一开始我们找不到一种简单的方法在 AIX 平台上运行带有 GUI 的 X Server。不过，如果没有 IDE，这倒不成问题。我直接在那台机器上安装了 Bash，然后像在自己的开发机器上一样操作它。

那时，我意识到无需IDE就能工作的真正优势在于远程机器。我可以跨多台机器对我们的产品进行基准测试，并测试负载平衡、防火墙等网络问题。如果出现错误，没关系，我只需添加一些调试打印，然后重新开始即可。这样一来，重建周期就缩短到不到一分钟，而不必使用构建机器重建调试版本。

谁应该考虑不使用 IDE 进行工作？

不使用 IDE 进行开发并非易事。这需要你对所使用的技术有深入的了解，并且需要熟悉所用操作系统的 Shell 环境。

不使用 IDE 的学习曲线比使用 IDE 的学习曲线更陡峭，因此不建议初学者使用。此外，不使用 IDE 带来的好处并不值得付出努力。通常情况下，初学者无需在远程机器上工作或在任务之间切换。

这种工作方式更适合那些频繁切换任务的技术主管；他们需要在几个小时内为某个新功能运行概念验证 (POC)、修复生产环境中的 bug，并审查新开发的功能。在这种情况下，如果在多个环境中工作，任务之间的上下文切换会便宜得多。

对于执行基准测试、生产中的错误调查、网络或任何需要在远程机器上运行的任务等 Ops 任务的开发人员来说，它也能很好地发挥作用。

不使用 IDE 进行开发调试

调试又是另一回事。我个人从来都不太喜欢 IDE 调试器，因为调试技巧与语言、IDE 和操作系统息息相关。这就是为什么即使我使用 IDE，我也很少使用调试器。相反，我更喜欢使用调试输出。它们适用于所有语言和所有平台。代码的建模方式应该能够让你轻松运行部分代码，而无需运行整个服务器。避免共享状态和解耦组件可以解决这个问题。

幸运的是，不使用 IDE 不会影响您在生产环境或预生产环境中的调试方式。这只会改变您的后端开发工作流程，因此您当前的所有监控工具都将照常工作（这意味着您仍然可以使用OverOps！😉）。

最后的想法

（已编辑）关于重构，我想说的是，使用 IDE 进行代码重构绝对更容易，因为它们内置了重构支持。如果没有 IDE，我会根据具体任务使用正则表达式或其他一些专用的小脚本。不过，使用正则表达式进行重构会让你成为专家，而且它是一个非常容易掌握的工具。Sublime 是我使用的主要文本编辑器，它可以非常快速地索引数千个文件，并允许你在不到一秒的时间内完成查找/替换。（/已编辑）

我不会试图说服你每个开发人员都应该立即删除他们的 IDE，然后开始像我一样工作。除了首次配置环境的工作（可能需要数周时间）之外，你还需要不时停下来进行维护，添加一些别名，删除其他别名，添加对新部署机制的支持等等。

对于任何熟悉 IDE 的开发者来说，都不建议这么做。但是，对于那些经常被 IDE 的性能和功能所困扰的人来说，你应该知道，即使没有它，也还是有办法的。

作者：David Levanon。最初发表于OverOps 博客