为什么有一部分程序员要用vscode作为自己的IDE

Question

我感觉vscode最多只能相当于一个代码的查看器和编辑器，无法作为编译器正常使用，因为：

vscode要想成为某一个语言的ide不仅要下载vscode内部的插件，还在在电脑中配置编译器，这个看起来就很奇怪了。

那么使用vscode编程的理由是什么呀？

Answer 1

首先告诉你一个事实：在现代软件中，编辑器直接和编译器作为一个程序发布的，才是很奇怪。

====一：编辑器和编译器分离很奇怪？====

与被VS惯坏了的那些新手工程师们的想法恰恰相反，这世界上多数IDE的编辑器和编译器都是分开的，最多是对某些兼容好一些，而另一些差一点。

VS：Visual Studio表面上集成度很高，是最可能被拿来反驳我的开篇结论的例子。但实际上，VS中编译器和编辑器也是分开的。它的编译器支持MSVC工具链和clang，可以用json配置，也能用MSBuild配置。甚至也可以不配置，编写完了直接在外部命令行调用MSVC命令行。

Dev-Cpp：你是可以更换、配置编译器的。愿意的话，你可以用MSVC，甚至可以用自己写的编译器。

XCode：有些平台上，它的默认编译器是clang。显然地，这需要你有一个clang编译器，并不是你安装编辑器本身就可以；一般来讲你不需要在安装IDE的同时额外安装编译器，但那是因为IDE发行者一般打包好了第三方编译器，这并不是说文本编辑器可以完成编译器功能。

Vim和Emacs：编辑工具中的鼻祖，不多解释。

结论：在文本编辑器的同一个程序中集成编译器功能，不是不可以，但没有任何主流软件这么做。另外从你的问题看来，你有一个严重的误区，那就是误以为“IDE就是编译器”。这个想法完全不正确，尽管有不少人这么想。包括VS、Dev在内的IDE也完全不是编译器，它们只是调用编译器而已。

====二、集成开发环境（IDE）的误解和真相====

很多新手工程师（甚至是工作了一定年头的工程师）错误地认为，IDE和编译器是同样的东西。实际上本文中“编译器”的用词也是不准确的，正确用词是“编译套装”“工具链”“工具集”。严格意义上的编译器只是工具链的一部分，只使用狭义上的编译器是不可能得到可执行的程序的，除非你打算用内联汇编写裸机程序，而且不调用任何外部编译模块。（你还需要链接才能得到可执行程序。）

IDE只是把编辑器、编译器、调试器、二进制工具等等东西集成在了一起而已，但**这完全不等于“这些东西是一样的”或者“这些东西就应该被集成”**。类似这样的想法是相当错误的。事实上，有时候我们在跨平台开发中还会避免过度依赖IDE的集成功能。IDE只是为了方便工作诞生的东西，它的存在简化了很多原本不必你来做的事情，但是**“简化了工作”不等于“被简化的工作不需要做”**。IDE只是帮你完成了调用而已。

结论：IDE做的并不是“在文本编辑器中直接集成一个工具链”，而是“提供方便的接口可以让你在使用文本编辑器后立即调用工具链”。工具链和IDE仍然是分离的。

====三、为什么要分离编译器和编辑器====

答案异常简单：如果把编译器和编辑器写在一起，那么很多功能会难以实现。这是工程上的考虑。

工程上有个非常重要但经常被初学者忽略的原则：低耦合模块化设计。一个软件模块该做什么就做什么，不要去管不相关的事情，哪怕两个工作高度接近。文本编辑器就是编辑器，编译器就是编译器，它们的定位完全不同，它们的工作应当由不同的两个程序完成（我们已经说到过，IDE只是把这些模块组合在一起而已，而并非一个模块），从这个原则出发，这是理所应当的事情。

那么，为什么要有这样的原则？原则存在的理由绝对不是为了把工作变得麻烦，事实上，这个原则有着充分的理由。

工程上我们经常听到一个词：耦合。通俗来讲，耦合就是指模块之间的关联度。有位大牛曾经说过：“计算机工程中，人是第一位的，计算机是第二位的。”这其实是说，计算机工程中，你要确保人能读懂你的代码，不能觉得编译通过、运行正常就万事大吉了。把完全不相关的不同功能写在同一段代码、同一个程序内，不是不可以，但这样会导致软件可维护性非常糟糕。这也是为什么我们讲，界面和逻辑一定要分离。写代码时，把前端显示和后端调用逻辑全写进按钮事件里，并非不能完成功能，但这样的话，修改起来非常困难。如果后端功能不改，但前端大改，之前写的一堆前后端逻辑杂乱的js代码毫无疑问会成为整个工程中最大的bug来源。

以这样的逻辑，我们可以得出一个显然的结论：一旦一个工程达到上千行乃至更多的程度，如果不在架构设计上进行解耦，整个项目就会变成没人想维护的bug集合体——不同功能写在一起，各种模块的引用交织，会导致没人能看懂代码，尝试修正的结果也只能是巨量bug。

因此，要正确、高效地实现一个IDE这样的大型工程，必须对各个模块进行解耦。这就决定了：文本编辑器不能代劳编译器的功能。

除了可读性的原因外，还有一个重要原因。不同平台上编译器的逻辑是完全不同的。平台有很多划分方式，操作系统有Win、Debian、RH、Mac等，指令集架构有x86、arm、riscv等，同一个指令集架构的硬件架构实现又五花八门。而且，仅仅是平台众多属性中的一个不同，编译器的内在逻辑就是完全不同的。例如，同样是Win，x64上的编译器和arm上的就不同，arm上根据有没有FPU、是el还是hf又有不同，x64上根据是否支持SSE、是否支持MMX又有不同。一言以蔽之：编译器在不同目标平台上的具体实现千差万别，就算不考虑发行版和语法标准，每个语言也至少要为几十个主流平台发行编译器。（PC只是众多平台类型中的冰山一角，机床、移动设备、特种设备等等，使用的平台都是千变万化。新人常常错误地认为x64/Windows平台是绝对的主流，而实际上这样的想法是绝对的谬误。）如果文本编辑器内置编译器功能，那么就连编辑器也要发行几十个主流版本，但这有必要吗？图形库基本是OS或图形协议本身规定和实现其底层，同一OS中，无论是什么指令集，其API是基本不会变的，也就是说，每个操作系统要发行很多很多个不同的编译器，但编辑器不需要那么多。如果编辑器也发行那么多，工作量很大，容易出错，还会导致repo体积大很多，这会间接延长build耗时。

====综合结论====

现在的主流IDE其实都是编译器和编辑器分开的设计，只是底层调用过程被掩盖了，但这不表示它不存在。（这正是很多人的误区所在，也是为什么我说很多工程师被VS惯坏了。VS简化了许多底层调用，导致新人错误地认为这些调用不存在而是同一程序的内部通信。当然，不得不承认，VS很好用。）这样设计的根本原因是为了保证低耦合度，进而保证效率、质量、可维护性，同时也能减少需要的build工作量。解耦合很有益，而且非常有必要。

VSCode需要安装插件不是什么大问题，本质上VS、Dev等也是通过类似于调用插件的方法实现项目编辑和构建的（只是这些IDE内部名称不是插件而已），只是VS、Dev等自带这些“插件”，而不是不需要插件。事实上，VSC这种设计极大地扩展了它的使用范围和可用性，它的可用性比VS、Dev都要大很多。