公众号关注 “教程”

设为 “星标”，每天带你逛 GitHub！

来源 | 李少侠 /.zhihu.com/p/

VS Code（ Code）在近些年实现了迅猛发展，已然成为众多开发者工具箱中的核心利器。作为一项开源软件，它同样吸引了众多第三方开发者以及终端用户的关注，跻身于顶级开源项目之列。在功能上，它满足了基本需求；在用户体验上，它表现得相当出色；即便在拥有众多插件的情况下，它依然保持了简洁流畅的操作，这实属难得。

我是一名 VS Code 用户，并且致力于为其开发插件。在插件市场中，大量 Java 插件均出自我们团队之手。因此，在日常工作中，我对 VS Code 在工程领域的诸多优势有了深刻体会。现在，我将逐一对这些亮点进行详细讨论。

简洁而聚焦的产品定位，贯穿始终

你知道 VS Code 的开发团队人数只有二十出头吗？

令人难以置信，众人普遍认为 VS Code 功能全面，如此卓越的工具竟是由少数人打造而成。实则，功能全面只是一种错觉，因为众多针对特定编程语言和技术的能力实际上是由第三方插件所赋予的。VS Code 的核心功能始终保持简洁，这对产品团队的能力提出了严峻考验：若功能过多，则可能导致产品臃肿，且人手不足；若功能过少，则显得力不从心，难以吸引用户使用。

他们的团队决定将主要精力投入到核心功能的打造上，致力于为用户带来简洁且流畅的使用感受，同时这一理念在产品开发的各个环节都得到了体现。在我眼中，这无疑是该产品的首个显著优势。

首个特点既是挑战所在，因为所谓的“简洁”实则指代产品的“外观”，而真正核心的则是前期的定位问题——产品究竟要解决何种问题。若从用户视角出发，这个问题可以细化为以下数点——我们为何需要一款新工具？它究竟是代码编辑器，抑或是集成开发环境（IDE）？让我们来看看项目负责人 Erich Gamma 的说法：

视频截图展示了 Erich 对 VS Code 的角色进行了阐述，将其定义为：一款编辑器，具备代码理解功能，以及调试能力。

这幅图像揭示了 VS Code 的核心定位——它集成了编辑器、代码解析以及调试功能。这样的设计既克制又均衡，它专注于满足开发者日常最频繁使用的需求，并且在产品形态上追求简洁与高效。观察其成效，这一定位显然是相当成功的。

在这一定位的引领下，这些工程师们成功研发了 VS Code。其相对简洁的功能集合，让开发者得以在代码品质上追求极致，而最终用户也因此获得了性能卓越的工具，这也是 VS Code 在众多编辑器中脱颖而出的关键所在。

由于产品定位严格且团队职责明确受限，成员们得以将精力集中于此类问题，进而创作出经得起考验的高质量代码。

与此同时，较小的团队确保了成员们在行为上的高度一致性，这一点在社区交流中尤为突出。大家可以在相关平台上观察到他们的表现，那些超出产品定位范围的请求和反馈大多遭到了婉拒或转交至第三方插件项目，这充分展现了他们的专注度。

浏览至此，情形看似顺利，然而问题随之浮现——程序员众多，有人偏爱 Node，有人青睐 Go，有人专攻前端，有人负责后端，VS Code 又该如何满足这些多样化的需求呢？聪明的你或许已经想到了答案——丰富的插件资源。那么，现在我们就来深入探讨一下 VS Code 是如何构建和维护这样一个庞大的插件生态系统的。

进程隔离的插件模型

使用插件来增强功能已成为常见做法，然而，如何确保这些插件与原生功能同样出色呢？历史经验表明：这并非易事。

大家不妨看看，这些插件模型可以说是做到了极致，功能上几乎无所不能，然而却有几个让人头疼的问题：它们不够稳定、操作起来有些麻烦、速度也不快，因此许多用户选择了转向其他怀抱。可以说，插件既成就了它们，也导致了它们的失败。

问题的核心在于信息的不均衡，这造成了不同团队所编写的代码在思路和质量上存在差异。结果，用户只能得到一个既混乱又卡顿的产品。因此，要让插件在稳定性、速度和用户体验上与原生功能保持一致，只能是一种理想化的期待。

观察其他集成开发环境的设计，独立实现所有功能并达到卓越水平，使得他人无需再费心，从而赢得了“全球最佳IDE”的赞誉；类似地，无需额外配置，即可直接使用，插件并非必需。看来独立完成所有任务似乎是个不错的选择，然而，大家可能并不了解，这背后其实有成百上千人的专业团队在默默付出。显然，这样的规模并非仅靠 VS Code 的二十几位成员就能胜任。他们决定开放平台，让用户开发插件，那么，面对这些挑战，我们又该如何应对呢？

这里要告诉大家一个小秘密——这款软件的核心开发者正是当初的 VS Code 团队成员。正因为如此，他们深知事物总是在不断变化的。与某些软件不同，VS Code 则是选择了将插件进行封装管理。

首先，这种做法旨在解决稳定性问题，这对于VS Code而言尤为关键。众所周知，VS Code的底层基于Node.js，本质上是一个单线程的环境，一旦代码出现崩溃，后果将不堪设想。因此，VS Code选择对任何插件都持有不信任的态度，将它们置于独立的进程中运行，尽管它们可以任意操作，但主程序却能保持稳定运行。

插件与主进程隔离

这一决策的制定并非毫无缘由，正如先前所述，团队中众多成员原本是某机构的成员，因此对于该机构的插件模式有着深刻的理解。他们的设计理念之一便是将组件化理念发挥到极致，因此许多核心功能均通过插件的方式进行实现。遗憾的是，该插件运行于主进程之中，一旦插件表现不佳或出现不稳定现象，便会直接对主进程造成影响，导致最终用户普遍反映程序显得庞大、运行缓慢且不稳定。VS Code 通过进程的物理隔离实现了这一问题的有效解决。实际上，这种进程级别的隔离也引出了另一个值得探讨的话题，即界面与业务逻辑之间的隔离问题。

UI 渲染与业务逻辑隔离，一致的用户体验

不稳定之后的问题在于其难以使用，具体表现为界面和操作流程的杂乱无章。造成这一现象的根源在于插件间界面语言的“不一致”，这使得学习过程变得尤为艰难，遇到问题时也缺乏统一的解决方案。而 VS Code 的处理方式则是完全杜绝插件“创造”新界面的可能性。

如所示图解，插件被隔离于Host进程之中，与此同时，用户界面部分则运行于主进程，因此插件们无法直接在用户界面上进行任何操作。

VS Code 对用户交互入口进行统一管理，并确立了交互规范。用户的每一次操作都会被转换成不同的请求，发送至插件进行处理。插件的工作仅限于对这些请求做出响应，并集中处理业务逻辑。然而，插件始终无法“决定”或“影响”界面元素的渲染方式，包括颜色、字体等方面。至于弹出对话框等操作，更是遥不可及。

VS Code在用户界面方面的掌控可以说是极为严谨，甚至有些过分，那些曾制作过插件的用户应该深有体会。有兴趣的同学不妨深入了解其历史，这样能更直观地感受到。初看之下，第三方开发者似乎被严格限制，这难道不是限制了大家的创造力吗？但我想说的是，这种做法与该团队的背景有着密切的联系，如果换一个团队，很可能无法取得成功。他们之所以取得成功，主要得益于该团队在开发工具领域深耕细作多年。他们不仅将丰富经验转化为独到见解，而且将这些见解具体体现在 VS Code 的界面设计和交互语言中。观察其成果，不难发现它们受到了广泛的喜爱和认可。

界面与业务逻辑的完全分离，确保了所有插件展现出统一的行为模式，从而使用户享受到一致且有序的体验。此外，这种在接口及行为层面的统一性，最终演变成了一个“卓越”的功能——这一点我们将在稍后进行探讨。接下来，我们将讨论 VS Code 的又一创新举措—— 。

LSP—— 基于文本的协议

前文已经指出，VS Code 在定位上具有两大亮点：代码解析与调试功能，而这些功能大多依赖第三方插件来完成。其中，连接这些功能的纽带是两大协议——语言服务器协议（LSP）和调试协议（DAP）。从设计层面来看，这两者极为相似。接下来，我们重点探讨一下最为热门的LSP。那么，为何需要LSP呢？

全栈开发已成为当今时代的潮流，软件从业者们的视野也愈发宽广，不再局限于单一的语言或技术，这无疑对我们所掌握的技能提出了更高的要求。

以一个例子来说，我采用 和 Node.js 进行前端开发，后台则使用 Java 编程，偶尔还会运用 进行数据挖掘。在这种情况下，我可能需要整合多种工具，然而这种做法的弊端在于，我需要在不同的工具之间频繁切换，这不仅会消耗系统资源，也会影响用户体验，总体上显得效率低下。

那么，是否存在着一种软件，能够在同一工作区域内处理这三种语言呢？答案是肯定的，那就是 VS Code——一款具备多语言开发功能的平台，而其多语言支持的根本在于（LSP）。

短短数年间，该协议实现了前所未有的成就，截至目前，已有包括微软在内的一百多家大公司和社区参与其中，实现了对几乎所有主流编程语言的全面覆盖。此外，它还被诸如Atom、Vim、Emacs等众多开发工具所接纳，这一事实从侧面彰显了其卓越品质。

尤为难得的是，这份协议实现了轻便快捷，堪称 VS Code 的杀手锏功能，并且也是微软极为重要的知识产权之一。哇塞，既强大又轻便，这简直让人难以置信，仿佛是个骗局。那么，我们就来探究一下它是如何实现这一点的吧。

先划重点：1、节制的设计 2、合理的抽象 2、周全的细节。

首先谈谈设计方面，追求全面性是常遇到的问题。假若让我负责设计一个旨在支持所有编程语言的工具，我的首要想法很可能是构建一个囊括所有编程语言特性的综合集合。

微软曾进行过类似尝试，例如——开发了一个不受特定语言限制的编译器，C#与VB.NET的编译器均以此为基础构建。众所周知，C#在语言特性方面极为丰富，这一点足以证明其强大之处。然而，问题随之而来，为何它并未在社区中得到广泛的应用呢？我认为，这主要是因为“强大”这一特性所带来的负面影响：复杂性和主观性。语法树的构成本身就相当繁复，而其中包含的其他特性及其相互间的联系更是难以捉摸，如此庞大的结构，对于一般的开发者来说，实在是不易轻易尝试。

相比而言，LSP 明显将简约作为设计理念之一，致力于打造最小化集合，始终秉承着团队一贯的克制风格。它专注于用户在编写代码过程中频繁操作的实际对象（诸如文件、目录）以及状态（如光标的位置）。它并未试图深入理解编程语言的特性，编译过程也不是其关注的焦点，因此并未涉及诸如语法树等复杂的理论概念。

这并非一蹴而就的成果，而是伴随着 VS Code 功能的不断更新而逐步完善。因此，自其问世以来，它始终保持着轻巧的身姿，易于理解，入门难度较低，很快在社区中获得了广泛的认可，各种语言的（LS）应用如雨后春笋般涌现。

虽规模不大，但功能却不可忽视，因此抽象性显得尤为关键。在LSP中，动作与位置是最核心的概念，绝大多数的请求实际上是在表述“于既定位置实施既定动作”。

以一个例子来说明，当用户将鼠标指针停留在某个类别名称之上时，他们可以浏览与之相关的定义和文档资料。在此过程中，VS Code 会向 LS 发送一个 '/hover' 类型的请求，其中包含的核心信息是当前文档的具体位置以及光标所在的具体位置。LS在接收到请求后，会进行一系列内部处理，包括识别光标所在位置对应的符号，以及定位相关文档。随后，LS会提取相关信息，并将其发送回VS Code，以便用户查看。这一来一回的交互过程，在LSP中被简化为请求和回复两种形式，同时LSP还对其规格进行了详细规定。开发者眼中，概念数量有限，交互方式相对简便，实现过程亦较为轻松。

浏览至此，大家或许对LSP有了更为深入的认识，它实际上是一种粘合剂，将VS Code与众多语言的LS紧密连接。然而，它并非一般意义上的粘合剂，而是一种极具鉴赏力的粘合剂，这种鉴赏力正是体现在其细节之处。

这首先是一种以文本为基础的通信协议，其文本特性显著降低了理解和调试的复杂度。借鉴HTTP和REST的成功经验，我们很难设想，若采用二进制协议，将会面临何种困境。事实上，即便是同为文本协议的SOAP，也早已被淘汰，这一现象充分证明了“简单性”在构建开发者生态系统中的关键作用。

这无疑是一个基于JSON的协议选择，而JSON无疑是结构化数据格式中最易于阅读的一种。只需观察各代码仓库中的配置文件格式，便能明了这一决策的正确性。如今，还有谁在新项目中使用XML呢？再次强调——“简单”。

此外，该协议建立在某种基础之上，鉴于JSON的广泛流行，众多编程语言均对其提供了出色的兼容性，因此开发者在序列化和反序列化方面无需费心，这在实现层面可谓“简便”。

从这些细微之处，我们可以明显看出，VS Code 开发团队对当前技术潮流的洞察力极为敏锐，他们的决策过程充分体现了“简洁”原则，并深得社区开发者的青睐。因此，有必要反复强调：

在做设计的时候一定要倾向于简单。

在做设计的时候一定要倾向于简单。

在做设计的时候一定要倾向于简单。

集大成的

今年五月，VS Code 推出了 VSCRD，借助这一功能，我们便能在远程环境，诸如虚拟机或容器中，启动一个 VS Code 工作区，随后再通过本地的 VS Code 连接至该工作区进行操作。以下图片展示了其运作方式：

VSCRD 在根本层面上提升了远程开发的操作感受，相较于普遍采用的远程桌面共享技术，其具体优化点包括：

快速响应：VSCRD 的所有操作均在本地用户界面内进行，反馈迅速；而远程桌面传输的是屏幕截图，导致数据传输存在较大延迟，因此经常出现卡顿现象。

遵循本地配置：VSCRD的用户界面在本机运行，完全依照本地设定，因此用户可以继续使用熟悉的快捷键、界面布局和字体选择，从而减少了因不适应而造成的工作效率损失。

数据传输成本较低：远程桌面主要传输视频数据，而VS Code则是传输操作指令及其反馈，其开销与命令行相似，卡顿现象也因此得到了进一步的缓解。

在远程工作环境中，不仅 VS Code 的内置功能得以使用sublime text 多好，而且所有第三方插件的特性同样不受限制；至于远程桌面，则需要您逐一进行安装。

远程文件系统功能齐全：该系统已完全与本地文件系统对接，两者在操作上几乎无异。

那么，VSCRD究竟采取了哪些令人称奇的手段以达致这样的效果呢？不妨先来观察它的结构图：

其实答案都在前文有所提及：

进程级别隔离的插件模型

若Host（即图示中的VS Code）与主程序实现了物理层面的分离，那么无论是将Host部署在远程还是本地，其运行的本质并无差异。

UI 渲染与插件逻辑隔离，整齐划一的插件行为

所有插件的用户界面均由VS Code集中渲染，因此插件内部仅包含纯粹的业务逻辑，其行为表现高度一致，无论在何处运行，均无差异。

高效的协议 LSP

VS Code所采用的LSP和DAP两项协议设计得极为简洁，它们天生适应网络延迟较大的环境，因此在远程开发领域应用得尤为合适。

VS Code 团队在构建架构时展现出了远见卓识，而且他们对每一个细节的处理都达到了极致。正因如此，VSCRD 这样的功能才得以问世，我认为这堪称是集众多优点于一体的杰作。

尚未体验过VSCRD的同学，不妨再向大家推荐一番，这款工具在诸多场合下都表现得尤为实用。

配置开发环境相对复杂，以物联网开发为例，需自行安装并调整多种工具与插件。在 VSCRD 中，只需使用一个远程工作区模板即可轻松完成，若需要额外安装工具sublime text 多好，也只需进行简单的调整，过程十分简便。此外，这里还提供了众多常用编程语言及场景的模板。

本地设备性能有限，导致一些开发任务难以完成，例如机器学习项目，这类任务对海量数据和强大的计算能力有较高要求。在VSCRD环境中，用户可以便捷地访问远程文件系统，并利用远程的计算资源。

最后

VS Code 如同一颗璀璨的星辰，吸引了众多开发者纷纷为其贡献力量。在这款软件的成功背后，我们见证了优秀的设计与严谨的工程实践所能成就的辉煌。在软件产业中，各领域的模式正不断被创新，既令人振奋，同时也对从业者提出了更高的技能要求。从个人学习的角度来审视，深入探究这些模式形成的来龙去脉，以及掌握工程实践中决策的形成过程，这对提升个人的工程技能大有裨益。

如有侵权请联系删除！