Understanding Visual Studio Code architecture
This chapter gives an overview of several software architectural views and perspectives, and describes the structure of the project.
Context
Visual Studio Code is a lightweight open source text editor developed under Microsoft and can be contributed to through the GitHub repository vscode. Extra functionality for Visual Studio Code is provided by means of extensions, which can also be developed by third party developers.
Architecture
Visual Studio Code consists of a layered and modular core that can be extended using extensions as seen in the Figure A. Extensions are run in a separate process referred to as the extension host, which utilises the extension API
The core of Visual Studio Code is partitioned into the following layers:
- base: Provides general utilities and user interface building blocks
- platform: Defines service injection support and the base services for Visual Studio Code
- editor: The “Monaco” editor is available as a separate downloadable component
- workbench: Hosts the “Monaco” editor and provides the framework for “viewlets” like the Explorer, Status Bar, or Menu Bar, leveraging Electron to implement the Visual Studio Code desktop application. Next the layers are detailed and the functionality of each is explaine
VSCode includes the main process and rendering process. At the same time, because VSCode provides the extension ability of plug-ins, and for the sake of security and stability, there is another Extension Host in the figure. In fact, this Extension Host is also an independent process for running our plug-in code. And like the rendering process, they are independent of each other. The Extension Host Process exposes some VSCode API s for plug-in developers to use.
A set of rules have been defined which each part must obey:
- There cannot be any dependency from outside vs/workbench/parts into vs/workbench/parts.
- Every part should expose its internal API from a single file (e.g. vs/workbench/parts/search/common/search.ts).
- A part is allowed to depend on the internal API of another part (e.g. the git part may depend on vs/workbench/parts/search/common/search.ts).
- A part should never reach into the internals of another part (internal is anything inside a part that is not in the single common API file)
What is the best architecture?
Recall that architects play a game of trade-offs. For a given set of functional and quality requirements, there is no single correct architecture and no single “right answer.” We know from experience that we should evaluate an architecture to determine whether it will meet its requirements before spending money to build, test, and deploy the system.
A good system architecture exhibits conceptual integrity; that is, it comes equipped with a set of design rules that aid in reducing complexity and that can be used as guidance in detailed design and in system verification.
Conclusion
The goal of this was researching the open-source project Visual Studio Code and presenting a description on the software architecture.
In the essay is concluded that the architecture is divided in different layers and that continuous integration tools and linters are used for maintaining code quality. The essay also indicates the importance of a structured architecture that can ever be improved so that code quality can be maintained, even with many developers contributing. There is still room for improvement in technical debt, like test coverage what is lacking behind.
References
Beatuful Architecture by Diomidis Spinellis