在我的职业生涯中，担任过许多不同的角色，从开发人员到首席执行官，以及介于两者之间的几乎所有职位，但是我一直在不断进步。

对我来说，这不仅是一种乐趣，而且最重要的是，它对于继续理解和掌握我们所处的超技术和超快速发展的环境至关重要。

我知道这是一个有争议的话题，但我认为首席技术官、工程经理，甚至首席开发人员应该知道如何编码，而且必须编码，无论是专业还是个人项目。

在这 20 多年的或多或少密集的软件编程过程中，我有机会使用各种各样的开发工具和IDE。

最近，我逐渐放弃了最复杂的工具，转而追求轻便和高效。

让我来介绍一下我的历程。

21 世纪的我

我在 21 世纪初进入了专业开发市场。

当时互联网泡沫已经破灭，但 Web 开发仍在蓬勃发展。

90 年代开发的“面向 Web”的语言（即除 C、C++ 之外的所有语言）（JavaScript、Python、PHP、Java 等）正在不断改进，开发工具也紧跟这一趋势。

这是Eclipse IDE（2001 年发布）、Visual Studio（1997 年）以及其他已基本消失的 IDE的鼎盛时期。

这也是一段徒劳地抵制专有环境（如 SunOS、HP-UX 和 AIX）中更专业化工具的时期。

当时，我必须在众多的选择之间做出选择，但又不能对其中任何一个产生特别的依赖。

2010–2020

2010 年，我发现自己担任一家拥有 3,000 名员工的公司的首席信息官，而这家公司本身又隶属于一个拥有 140,000 名员工的大型集团。

我的职责转向管理，但幸运的是我设法保持与技术总体和代码具体的密切联系。

这也是我发现 IntelliJ——它是Java 专家的首选 IDE 的时期。

2017 年，我与他人共同创办了一家初创公司，其使命是开发一个通过合同自动化来管理医护替代人员的平台（可称为一种医护界的 Uber）。

担任这家公司 CTO 后，我又回到了密集编码模式，以前这家公司只有我和合伙人，我必须设计整个系统，开发 MVP 以及后续步骤。

IntelliJ 仍然是我的主要工作工具，不再用于 Java，而是用于 Scala（它知道如何很好地处理）和 GoLang（它也知道如何很好地处理）。

“智能”自动完成功能开始看起来令人信服，并且该工具的范围不断扩大（数据库管理、从代码进行 SQL 查询、针对数据库模式的代码一致性检查、HTTP 查询管理以测试 API 等）。

随着 2020 年的临近，所有这些功能所暗示的工具繁琐性开始让我感到厌烦。

我们为初创公司招募的一些开发人员更喜欢使用已经成熟的VSCode 。

我们于 2020 年出售了自己的初创公司，然后我成立了自己的咨询/开发公司，主要参与曾接洽的两个项目。

第一个项目是帮助一家医学影像软件公司重新整理和更新产品目录。第二个项目是设计、开发和部署孟加拉国农业普查所需的所有软件和基础设施。

再一次，我发现自己处于必须“亲自动手”的境地，这次主要使用 Rust 和 Golang（还有很多 Kubernetes yaml 文件……）。

VSCode 仍然是我首选的工具，但与 IntelliJ 一样，我使用它的时间越长，就越能意识到它的小延迟、速度减慢和错误。

我突然想到，我职业生涯开始时有机会使用的那些老好工具（例如VIM）可能需要发展了，而且可能可以实现相同的生产力水平，而不必担心使用越来越像 Eclipse 及其所有插件的 VSCode。

期间，我参加了一个开发者大会，会上主讲人对NeoVIM做了一个非常有说服力的 demo （应该是定制化的），最终让我信服了。

因此，我开始花费大量时间尝试正确配置 NeoVIM，并意识到这几乎是一项全国性运动（Youtube上面有成千上万个视频，里面的人默默拍摄自己配置 NeoVIM 的视频，而且我敢肯定 Twitch 上也有相同主题的视频）。

现在

如今，我是一名“服务部门经理”，这是我在现任雇主处设立的职位类型之一，旨在解决产品停滞、团队重新活跃和所有权执行的问题。

基本上，我管理一个负责产品（在本例中是云提供商的 IAM）的团队，从设计到运行，当然也包括软件开发。

我的职责是管理一个小型（但多技能）的团队完成所有这些阶段。

再次，我的时间被分配到管理、产品定义、基础设施管理以及开发之间。

2021 年底，我偶然发现了Helix （我当时正在寻找 NeoVIM 的 Rust 版本）。

Helix 是一种“内置电池”的 NeoVIM，即兼具两全其美的优点：终端模式（模态）编辑器的轻便性和效率，而没有 NeoVIM 所需的配置和插件的混乱。

虽然这是一个相对较新的项目，但它发展迅速，现在已经完全成熟，可以用于日常使用，无论是用于编码、编写文档、管理我的笔记和待办事项、制作我的美人鱼图表等……

它可以通过 LSP 协议（由 Microsoft 通过 VSCode 推广）轻松扩展，因此您会发现与任何更重的 IDE 相同的自动完成、诊断和操作建议功能。

它还没有定义插件系统，这有点违背了它的初衷。但在社区的压力下，它的创建者最终让步了，并且它正在不断发展。

那么，为什么要使用基于终端的模态编辑器？

在Cursor和其他支持 AI 的 IDE 变得越来越复杂的时代，这种选择可能看起来违反直觉，甚至适得其反。

这确实与工具竞赛相反，但随着时间的推移（以及随之而来的智慧，必定会有一些优势），我意识到这些工具最终会在我的大脑和我的代码之间产生“噪音”。

这些工具的目的是通过自动执行某些任务和隐藏某些复杂性（例如，编译选项的粗糙度或用于启动调试或单元测试会话的参数）来提高开发人员的工作效率。

这最终会导致开发人员和他实际交互的工具（主要是编译器）之间的距离。这一距离引发了几个问题：

• 首先，如果没有自己喜欢的 IDE，开发人员将无法再开发或编译他的程序（之后编写 CI 脚本并不容易）。

• 其次，但这只是个人观点，我发现它们不利于代码结构的心理表征。您只需单击一下即可从函数签名导航到其调用，再单击一次即可浏览树形结构（这可能非常令人困惑），最终您无需付出记住代码结构所需的记忆努力。然而，这种心理表征对于持续改进代码至关重要。开发人员不仅仅是在 IDE 前思考（这可能甚至微不足道）。

当你使用 Helix（或 NeoVIM）等编辑器时，会感觉自己“更接近”代码。例如，Helix 没有树状的代码或文件结构表示，而是具有超高效和快速的搜索系统。

如果你对文件和代码结构有充分的了解，这种“缺乏”实际上会变得更加高效。

另一个同样重要的方面是习惯用户的工作速度。

浏览代码，选择一个单词、一个函数、一个函数的一部分，同时编辑它们——所有这一切都在一瞬间完成，无需离开键盘去拿鼠标或触控板。

对于纯文本编辑，模态编辑器对于那些花最少的努力去学习如何使用它们的人来说是无与伦比的，即使代码库有几十万行。

但 Helix 不仅仅是一个文本编辑器：它能够通过 LSP 协议使用外部工具，提供与更重的 IDE 几乎相同级别的信息和自动化：直接访问功能文档、自动完成、功能签名描述、代码结构索引（谁调用谁、谁被谁使用、谁实现了什么等）。

结语

模态的、基于终端的编辑器迫使您专注于代码，而不会受到干扰。如今，它们的效率令人难以置信，而且越来越全面。

然而，没有人工智能或 Copilot，你就得动脑筋了。也许这就是它没有针对如此广泛的受众的原因 ;-)

译者：聆听音乐的羊

作者：Bastien Vigneron
参考：
https://medium.com/codex/why-ive-abandoned-ides-8967d12ecde7