ソース知っている
著者LiShaoxia
今日はあなたのためにVSCodeについての記事を共有します：
Visual Studio Code（VS Code）は、近年爆発的な成長を遂げており、膨大な開発者ツールライブラリで必須のアーティファクトになっています。オープンソースプロジェクトとして、無数のサードパーティ開発者やエンドユーザーを魅了し、トップのオープンソースプロジェクトの1つになっています。機能的には十分で、経験上使いやすく、多数のプラグインを備えたシンプルでスムーズな機能であり、非常に称賛に値します。
VS Codeユーザーとして、プラグインも開発しています。プラグイン市場の多くのJavaプラグインは、基本的に私たちのチームの仕事です。そのため、日常業務でVSCodeのエンジニアリングのハイライトを数多く観察しました。それらについて1つずつ話し合いましょう。
全体を通して簡潔で焦点を絞った製品の位置付け
VS Code開発チームはまだ20代前半であることをご存知ですか？
信じがたいことですが、VS Codeは全能であると誰もが考えています。どうしてこんなに強力なツールを実行できる人は、こんなに少ないのでしょうか。実際、特定のプログラミング言語とテクノロジーのほとんどの機能はサードパーティのプラグインによって提供されているため、機能の豊富さは美しい幻想です。VSCodeのコアは常に非常に合理化されており、製品チームの能力をテストします。それを処理するには：多すぎる、肥大化、十分な人的資源がない;少数、弱すぎる、誰も使用しない。
彼らのチームは、コア機能の開発に焦点を当て、ユーザーにシンプルでスムーズなエクスペリエンスを提供し、このアイデアを製品開発のすべてのリンクに適用することを選択しました。私の意見では、これは最初の明るいスポットです。
「シンプルさ」は最終的な分析では製品の「形」であるため、最初の輝点も難しい点ですが、より重要なのは実際には事前の問題 、つまり製品の配置と問題点です。を解決します。ユーザーの観点から、この質問は次の点に翻訳できます-なぜ新しいツールが必要なのですか？それはコードエディター（エディター）ですか、それとも統合開発環境（IDE）ですか？プロジェクトリーダーのErichGammaが言ったことを見てみましょう。
（ビデオスクリーンショット-ErichがVS Codeの位置付けを説明しています：エディター+コード理解+デバッグ）
このスクリーンショットは、VS Codeの位置付けを示しています：エディター+コードの理解+デバッグ。これは非常に抑制されたバランスの取れた選択であり、製品の形でシンプルさと効率を追求しながら、開発者の「最も一般的に使用される」機能に焦点を当てています。結果から、このポジショニングは非常に成功しています。
このポジショニングの指導の下で、これらの20人のエンジニアがVSCodeを考案しました。比較的小さな機能セットにより、開発者はコード品質の卓越性を追求することができ、エンドユーザーも優れたパフォーマンスを備えたツールを入手できます。これは、VSCodeが群衆から際立つ重要な理由です。
チームメンバーがそのような問題に時間を費やし、テストに耐えることができるコードを書くことができるのは、製品の位置付けとチームの責任に対する高度な制御のためです。
同時に、チームが小さいため、チームメンバーは均一な行動をとることができます。これは、コミュニティの相互作用で特に顕著です。GitHubにアクセスして、問題を確認できます。製品の位置付けの範囲を超えたリクエストとフィードバックは基本です。すべて拒否されたか、サードパーティのプラグインプロジェクトに転送されました。これは非常に焦点が絞られていると言えます。
これを見ると、すべて問題ないように見えますが、問題が発生しています。何千ものコードファーマーがいます。Nodeを使用し、私はGoを使用します。フロントエンドを実行し、バックエンドを実行する場合、VSCodeはどのように適合しますかこれらの多様なニーズ？あなたはすでに機知に富んだ大規模なプラグインに答えました。それでは、VSCodeが巨大なプラグインエコシステムをどのように管理しているかを詳しく見てみましょう。
プロセス分離のプラグインモデル
プラグインを使用して関数を拡張するのが一般的ですが、プラグインがネイティブ関数と同じくらい優れていることを確認するにはどうすればよいですか？* *歴史は私たちに教えてくれます：保証はありません。****
プラグインモデルは非常に徹底的であり、機能レベルも全能であると言えますが、不安定、使いにくい、遅いなど、いくつかの厄介な問題があり、多くのユーザーがIntelliJを利用しています。プラグインと言えますが、プラグインです。
問題の本質は情報の非対称性にあり、それが異なるチームによって書かれたコードがアイデアと品質の点で一貫性を欠く原因になります。結局、ユーザーは厄介で行き詰まった製品を手に入れました。したがって、安定性、速度、およびエクスペリエンスの観点から、プラグインをネイティブ機能と統合することは良い願いです。
他のIDEがどのように機能するかを見てみましょう。VisualStudioはすべての機能を単独で処理し、他の人が何もすることがないように優れています。これは「宇宙で最初のIDE」としての評判も達成しています。 IntelliJはそれに似ており、開いています。ボックスはすぐに使用できます。プラグインはオプションです。すべてを自分で行うのは良い方法のようですが、Visual Studioの背後に何千人ものエンジニアリングチームがいることをご存知ですか？明らかに、これはVSCodeで処理できるものではありません。彼らは誰もがプラグインを実行できるようにすることを選択したので、Eclipseが直面する問題をどのように解決するのでしょうか。
ここで少し知識を共有します-Eclipseのコア部分の開発者は初期のVSCodeチームです。ええと、彼らは同じ川に二度足を踏み入れませんでした。Eclipseとは異なり、VSCodeはプラグインボックスを閉じることを選択しました。
これを行うことによって解決される最初の問題は安定性です。これはVSCodeにとって特に重要です。VS Codeは本質的にNode.js環境であり、シングルスレッドであるElectronに基づいており、コードのクラッシュは壊滅的な結果になることは誰もが知っています。したがって、VS Codeは単純に誰も信頼せず、プラグインを別のプロセスに配置し、投げさせてください。メインプログラムが配置されています。
プラグインはメインプロセスから分離されています
VS Codeチームのこの決定には理由がないわけではありません。前述のように、チーム内の多くの人々は実際にはEclipseの古い部分であるため、当然、Eclipseのプラグインモデルについて深く考えています。Eclipseの設計目標の1つは、コンポーネント化を極限まで推進することであるため、多くのコア機能がプラグインの形式で実装されます。残念ながら、Eclipseプラグインはメインプロセスで実行され、プラグインのパフォーマンスが低下したり不安定になったりすると、Eclipseに直接影響します。その結果、Eclipseが肥大化し、遅く、不安定であると誰もが不満を漏らします。VS Codeは、プロセスに基づいて物理的な分離を実現し、この問題を正常に解決します。実際、プロセスレベルの分離では、別のトピック、つまりインターフェイスとビジネスロジックの分離も発生します。
UIレンダリングは、ビジネスロジック、一貫したユーザーエクスペリエンスから分離されています
「不安定」の後の問題は「使いにくい」、特に混沌としたインターフェースとプロセスです。その理由は、プラグイン間のインターフェース言語の「不一致」であり、異常に急な学習曲線につながり、問題に直面したときに均一なソリューションパスはありません。VS Codeは、プラグインに新しいインターフェイスを「発明」する機会をまったく与えません。
上の図に示すように、UIがメインプロセスにある間、プラグインは拡張ホストプロセスでロックされるため、プラグインは当然、ユーザーインターフェイスを直接操作できません。
VS Codeは、すべてのユーザーインタラクションポータルを管理し、インタラクション標準を策定します。すべてのユーザー操作はさまざまな要求に変換され、プラグインに送信されます。プラグインが実行できることは、これらの要求に応答し、ビジネスロジックに集中することです。しかし、プラグインは最初から最後まで、インターフェイス要素のレンダリング方法（色、フォントなど、どれも）を「決定」または「影響」することはできません。ダイアログボックスのポップアップに関しては、さらに素晴らしいです。
VS Codeによるユーザーインターフェイスの制御は、異常に注意していると言えます。プラグインを実行したことのある人なら誰でも理解できます。興味のある学生は、TreeViewの歴史を深く掘り下げて、より直感的な体験をすることができます。一見、サードパーティの開発者は死に物狂いですが、これはすべての人の創造性を制限しませんか？このアプローチはチームの背景と密接に関連しており、人の変化は失敗する可能性が高いと言いたいです。チームが長年開発ツールの分野で培ってきたおかげで成功し、彼らの経験をアイデアに変換し、最終的にVSCodeのインターフェース要素とインタラクティブ言語で実装しました。その結果、非常に人気があります。
インターフェイスとビジネスロジックは完全に分離されているため、すべてのプラグインの動作は一貫しており、ユーザーは均一なエクスペリエンスを得ることができます。それだけでなく、このインターフェースと動作レベルの一貫性は、最終的に別の「優れた」機能であるリモート開発に変わりました。これについては後で説明します。次に、VSCodeのもう1つの革新であるLanguageServerProtocolについて説明します。
LSP-テキストベースのプロトコル
前回の記事では、VS Codeポジショニングの2つの機能について説明しました。コードの理解とデバッグです。これらのほとんどはサードパーティのプラグインによって実装され、その間のブリッジは、Language Server Protocol（LSP）とDebug AdapterProtocolの2つの主要なプロトコルです。 （DAP）。この2つは設計の観点から非常に類似しており、最も人気のあるLSPに焦点を当てます。まず、なぜLSPが必要なのですか？
フルスタック開発は長い間この時代の主流になり、ソフトウェアの専門家は特定の言語やテクノロジーによる制限がますます少なくなっており、これも私たちの手にあるダイヤモンドに新たな課題をもたらしています。
たとえば、Javaでバックエンドを記述しながら、フロントエンドとしてTypeScriptとNode.jsを使用し、場合によってはPythonを使用してデータ分析を行います。その後、いくつかのツールの組み合わせが必要になる可能性があります。これに伴う問題つまり、ツール間で行う必要があるということです。システムリソースの消費やユーザーエクスペリエンスに関係なく、頻繁な切り替えは非効率的です。
それで、同じワークスペースで3つの言語すべてを処理できるツールはありますか？そうです、それはVS Codeです-複数の言語をサポートする開発環境であり、多言語サポートの基礎は言語サーバープロトコル（LSP）です。
この合意は、わずか数年で前例のない成功を収めました。これまでに、マイクロソフトやコミュニティなどの主要企業から、基本的にすべての主流プログラミング言語をカバーする100の実装がありました。同時に、Atom、Vim、Sublime、Emacs、Visual Studio、Eclipseなどの他の開発ツールにも採用されており、別の角度からその卓越性を証明しています。C / C ++ラーニングスカート[7、12、2、84、705]、初心者でも上級者でも、転職したいのか、キャリアを始めたいのか、一緒に理解して学ぶことができます！スカートには開発ツールがあり、乾物や技術情報をたくさん共有できます！
さらに称賛に値するのは、プロトコルが軽量で高速であるということです。これはVS Codeのキラー機能であると言え、Microsoftの最も重要なIPの1つでもあります。。。うわー、それは強力で軽量です、それはあなたがそれをどのように見ても詐欺です、そしてそれがそれをどのように行うか見てみましょう。
最初に重要なポイントを描きます：1。適度なデザイン2.合理的な抽象化2.思慮深い詳細。
最初にデザインについて話しましょう。大きくていっぱいになることは非常に一般的な問題です。私がすべてのプログラミング言語をサポートするようにそのようなものを設計した場合、最初の反応はすべての言語機能をカバーするスーパーセットである可能性があります。
Microsoftは、言語に中立なコンパイラであるRoslyn、C＃およびVB.NETコンパイラがそれに基づいているなどの試みを行ってきました。C＃には言語機能が非常に豊富であることは誰もが知っていますが、RoslynはC＃を十分にサポートしてその能力を発揮できます。それで問題は、なぜそれがコミュニティで広く使われていないのかということです。根本的な原因は、「強力さ」の副作用であると思います。複雑で意見が分かれています。構文木だけでもすでに非常に複雑であり、他のさまざまな機能とそれらの関係はさらに法外なものです。このような巨大なものは、通常の開発者が簡単に触れることはできません。
対照的に、LSPは、コンパクトさを設計目標の1つと明確に見なしており、チームの一貫したモデレーションスタイルを実装する最小のサブセットを作成することを選択します。これは、ユーザーがコードを編集するときに最も頻繁に処理する物理エンティティ（ファイル、ディレクトリなど）と状態（カーソル位置）を考慮します。言語の特性をまったく理解しようとはせず、コンパイルは問題ではないため、当然、構文木などの複雑な概念は含まれません。
これは1つのステップでは実行されませんが、VSCode関数の反復によって徐々に開発されます。そのため、誕生以来、本体は小さく、理解しやすく、実装のしきい値も低くなっています。コミュニティで急速に広く支持され、さまざまな言語の言語サーバー（LS）が至る所で開花しています。
小さくても小さくても、関数を小さくすることはできないため、抽象化は非常に重要です。LSPの最も重要な概念は行動と場所です。LSPの要求のほとんどは「指定された場所で所定の行動を実行する」ことを表現することです。
たとえば、ユーザーが特定のクラス名の上にマウスを置くと、関連する定義とドキュメントが表示されます。このとき、VSCodeは「textDocument / hover」リクエストをLSに送信します。このリクエストで最も重要な情報は、現在のドキュメントとカーソル位置です。LSは、要求を受信した後、一連の内部計算（カーソル位置に対応する記号の識別と関連ドキュメントの検索）を実行し、関連情報を検索して、ユーザーに表示するためにVSCodeに送り返します。このような相互作用は、LSPの要求（要求）と応答（応答）に抽象化され、LSPはそれらの仕様（スキーム）も指定します。開発者の観点からは、コンセプトは非常に少なく、インタラクティブなフォームも非常にシンプルで、実現は非常に簡単です。
これを見ると、誰もがLSPをよりよく理解する必要があります。LSPは本質的に接着剤であり、さまざまな言語でVSCodeとLSを一緒に接着します。しかし、それは普通の接着剤ではなく、細部に反映されている非常に上品な接着剤です。
まず第一に、これはテキストベースのプロトコルです。テキストは理解とデバッグの難しさを軽減します。HTTPとRESTの成功を考えると、これがバイナリプロトコルだとしたらどうなるか想像がつきません。テキストプロトコルでもあるSOAPでさえ、長い間亡くなりました。これは重要性を説明するのに十分です。開発者エコシステムの作成における「シンプル」の
次に、これはJSONベースのプロトコルです。JSONは最も読みやすい構造化データ形式であると言えます。この決定がどれほど正しいかを知るために、各コードウェアハウスの構成ファイルがどの形式であるかを確認できます。まだ人がいます。新しいプロジェクトでXMLを使用していますか？繰り返しますが、「シンプル」です。
繰り返しになりますが、これはJSONRPCベースのプロトコルです。JSONの人気により、主要な言語はJSONを優れたサポートでサポートしているため、開発者はシリアル化と逆シリアル化をまったく処理する必要がありません。これは実装レベルです。「シンプル"。
これらの詳細から、VS Codeチームによる今日のテクノロジートレンドの把握は非常に正確であり、彼らの意思決定は完全に「シンプル」であると見なされ、コミュニティ開発者の心をしっかりと把握していることがわかります。したがって、重要なことは3回言われます。
設計するときは、単純さに傾倒する必要があります。
設計するときは、単純さに傾倒する必要があります。
設計するときは、単純さに傾倒する必要があります。
統合リモート開発
今年の5月に、VS Codeはリモート開発（VSCRD）をリリースしました。これにより、リモート環境（仮想マシン、コンテナーなど）でVS Codeワークスペースを開き、ローカルVSCodeを使用して作業に接続できます。 、以下に示すように、その動作モードについて説明します。
VSCRDは、基本的にリモート開発のエクスペリエンスを向上させます。一般的に使用されるリモートデスクトップ共有と比較して、具体的な改善点は次のとおりです。
迅速な対応：VSCRDのすべての対話はローカルUIで完了し、対応は迅速です。リモートデスクトップがスクリーンショットを送信しているため、データのラウンドトリップ遅延が非常に大きく、スタッターが標準です。
ローカル設定を使用する：VSCRDのUIはローカルで実行され、すべてのローカル設定に準拠しているため、使い慣れたショートカットキー、レイアウト、フォントを引き続き使用して、作業効率のオーバーヘッドを回避できます。
データ送信のオーバーヘッドは小さい：リモートデスクトップ送信はビデオデータであり、VS Code送信は操作の要求と応答であり、コストはコマンドラインと同様であり、ストール状況はさらに改善されます
サードパーティのプラグインが利用可能：リモートワークスペースでは、VS Codeのネイティブ機能が利用可能であるだけでなく、すべてのサードパーティのプラグインが引き続き利用可能です。リモートデスクトップの場合、それらを1つずつインストールする必要があります。
リモートファイルシステムが利用可能です：リモートファイルシステムはローカルに完全にマップされており、2つはほぼ同じです
では、VSCRDは上記の効果を達成するためにどのような魔法の操作を行いますか？そのアーキテクチャ図を見てください：
実際、答えは前の記事で言及されています：
プロセスレベルの分離のプラグインモデル
拡張ホスト（つまり、図のVS Code Server）は、メインプログラムから物理的に分離されているため、拡張ホストをリモートで実行するかローカルで実行するかに本質的な違いはありません。
UIレンダリングとプラグインロジックは分離されており、プラグインの動作は均一です
すべてのプラグインのUIはVSCodeによって均一にレンダリングされるため、プラグインには純粋なビジネスロジックのみがあり、動作は高度に統一されており、どこで実行してもかまいません。
効率的なプロトコルLSP
VS Codeの2つの主要なプロトコルであるLSPとDAPは、どちらも非常に合理化されており、ネットワーク遅延が大きい状況に自然に適しており、リモート開発に最適です。
VS Codeチームのアーキテクチャ上の決定は、間違いなく非常に前向きであり、同時に、詳細の把握は申し分のないものです。VSCRDのような機能が生まれたのは、まさにその強固な工学的基盤のおかげであり、これは傑作だと思います。
VSCRDを試したことがない学生のために、ここに別のアムウェイがあります。これは次のシナリオで非常に役立ちます。
開発環境は、IoT開発など、構成が非常に面倒です。さまざまなツールやプラグインを自分でインストールして構成する必要があります。VSCRDでは、リモートワークスペースのテンプレートを作成できます。追加のツールをインストールする、つまりDockerfileを変更するのは非常に簡単です。一般的に使用されるプログラミング言語とシナリオのテンプレートはここにあります。
ローカルマシンは、機械学習などの特定の開発には弱すぎます。大量のデータとコンピューティングのニーズには、非常に優れたマシンが必要です。VSCRDでは、リモートファイルシステムを直接操作し、リモートコンピューティングリソースを使用できます。
やっと
VS Codeはまばゆいばかりのスターのようなもので、何千人もの開発者を引き付けて貢献しています。VS Codeの成功から、優れた設計とエンジニアリングの実践によっていくつの奇跡が生まれるかがわかりました。ソフトウェア業界を見ると、すべてのレベルのモデルが絶えず更新されています。これはエキサイティングであり、実践者は継続的にスキルを向上させる必要があります。個人的な学習の観点から、これらのモデルの誕生の原因と結果、およびエンジニアリングの実践における意思決定プロセスを理解することは、エンジニアリング能力を向上させるのに非常に役立ちます。
初心者の学習資料（チュートリアル、ツールインストールパッケージ）クリックして受け取る