マイクロソフトの著名なエンジニアであるエリック・ガンマ氏によると、Visual Studio Code が成功したのは、失敗したオンライン エディターをデスクトップ製品に転換したからだという。
Gamma 氏は昨日の仮想 VS Code Day で、世界で最も人気のあるプログラマーのエディター (または IDE?) がどのようにして誕生したのかについて講演しました。
2015年4月のBuildイベントで発表されたオープンソースエディタVS Codeは、リリースからほぼ6年が経ちました。Microsoftには既にVisual Studioという成功を収めた開発ツールがあり、この新しいエディタがWindows専用エディタの人気を凌駕し、わずか4年後にはEclipseのディレクターであるマイク・ミリンコビッチ氏が「開発エクスペリエンスの独占」への懸念を表明するほどになるとは、誰も予想していなかったでしょう。
ガンマ氏は、1994年に出版された画期的な書籍『デザインパターン：再利用可能なオブジェクト指向ソフトウェアの要素』の共著者であり、オブジェクト指向プログラミングの実証済みモデルを解説しています。彼はIBM Rational Softwareのディスティングイッシュド・エンジニアとしてJavaベースのEclipse IDEの開発に携わった際に、これらのアイデアを実践に移しました。当時RationalのCTOを務めていたリー・ナックマン氏によると、このプロジェクトと名称はどちらもMicrosoftをターゲットとしていたとのことです。「Eclipseは響きが良く、Visual Studioを凌駕するというアイデアが気に入りました」と、彼は2005年に語っています。
こうした野心にもかかわらず、ガンマ氏は2011年にマイクロソフトに入社し、ブラウザベースのコードエディタ「Monaco」プロジェクトの開発に着手しました。その最初の機能の一つが自動保存でした。「作業内容を失わないように、常に自動保存機能を有効にしていました。VS Codeのデフォルト設定を自動保存に変更する勇気はありませんでしたが、これは素晴らしい機能で、チーム全員が有効にしています」とガンマ氏は昨日のバーチャルステージで語りました。
昨日発表されたVS Codeの統計: 月間ユーザー数1,400万人、拡張機能数28,000件、解決済み問題数10万件
ガンマ氏は、JavaScriptに強力な型付けを追加するMicrosoftの別のプロジェクト、TypeScriptにも言及した。「コードの柔軟性を維持し、再構築を可能にするツールとしてTypeScriptがなかったら、この10年間の道のりは実現しなかったでしょう」と彼は述べた。TypeScriptはMicrosoftで2010年から開発され、2012年10月に公開された。2013年までに、Monaco/VS CodeはすべてTypeScriptで記述されていたとガンマ氏は述べた。
「多くの人が知らないことですが、私たちは最初から UI フレームワークを一切使わないと決めていて、それは今も変わっていません」と Gamma 氏は付け加えた。「パフォーマンスは私たちにとって非常に重要であり、自分たちの運命を完全にコントロールしたいからです。」
Visual Studio Online「Monaco」は、Azureのウェブサイトをブラウザで編集する手段としてリリースされましたが、ユーザー獲得には至りませんでした。「月間ユーザー数は約3,000人で、マイクロソフトにとってこのユーザー数で存在感を維持するのは非常に困難でした」とガンマ氏は振り返ります。10倍以上に成長しなければ、廃止される可能性もあったでしょう。
2014年が転換点だったとGammaは語った。チームは、GoogleのChromiumプロジェクトをラップし、ウェブアプリケーションをデスクトップで実行できるようにする、最近開発されたElectronフレームワークを用いて、プロジェクトをクロスプラットフォームツールとして再定義することを決定した。これは、ウェブアプリケーションがデスクトップアプリケーションになるという従来の流れに逆らうものだった。Gammaが公開した内部文書によると、このプロジェクトのコードネームは「Ticino」で、「マルチプラットフォーム開発、Node.jsアプリケーションとクロスプラットフォーム.NETコンポーネントのデバッグとデプロイメントを目的としたシナリオを持つ、ウェブ生まれの開発者」を対象としていた。エディタ以上の機能を備えつつ、完全なIDEよりも機能が少ない、両者のちょうど良いバランスを目指していた。VS Codeは翌年のBuildでプレビュー版が公開されるまでに完成していた。
次の画期的な出来事は拡張機能のサポートでした。拡張機能がなければVS Codeは広く普及することは不可能でした。ガンマ氏はEclipseでの経験を活かしました。「拡張機能は本当に素晴らしいものですが、弊害をもたらすこともあります」と彼は言います。「VS Codeコアが拡張機能の影響を少なくするため、拡張機能を別のプロセスで実行することにしました。例えば、保存はコアで行われるため、拡張機能が奇妙な動作をしたり問題が発生したりしても、保存には影響しません。」ガンマ氏によると、拡張機能APIは拡張機能ホストへのRPC（リモートプロシージャコール）を使用しており、これにより拡張機能の作者はVS Codeの内部実装の詳細を知る必要がなくなります。
この作業は迅速に進み、2015年10月に開催されたMicrosoftのConnectイベントで、VS Codeがオープンソース化されたことと同時に、拡張APIが発表されました。Gamma氏によると、その時点でMicrosoftは「オープンソースとオープンスタンダードの採用」こそが開発者を引き付ける正しい方法だと判断していたとのことです。
2015年10月のConnectイベントで、エリック・ガンマ氏（左）とマイクロソフトのクラウド担当副社長スコット・ガスリー氏がVS Codeをオープンソース化
2016年には、もう一つの重要な機能である言語サーバープロトコル（LSP）が導入されました。これにより、開発者はプログラミング言語のサポートをプラグインで実装できるようになり、構文の強調表示、コード補完、エラー検出といった機能を実現できます。次に、統合ターミナルが登場しました。これは、レドモンドにあるマイクロソフト本社を拠点とする新しいVS Codeチームによって開発されました。当初のチームはチューリッヒに拠点を置いていました。
リモート編集は、次の大きな課題でした。これは、Windows Subsystem for Linux（WSL）の導入と、GitHubリポジトリのコードを使ってブラウザでアプリケーションを実行できるというアイデアが一因です。「このリポジトリをVS Codeで開いて、F5キーを押すだけで実行できたらどうでしょう？」とガンマ氏は語りました。
これは、VS Codeをよりブラウザアプリケーションに近い形に戻すことを意味しており、より多くのリファクタリングが必要でした。Node.js APIへの直接呼び出しは削除され、サービスは抽象化されました。例えば、「デスクトップではネイティブダイアログが表示され、ブラウザではHTMLで構築されたダイアログが表示される」と彼は述べています。リモート開発は現在、WSLとDockerコンテナ内でのVS Codeの実行の両方をサポートしています。また、GitHubの機能であるCodespacesはクローズドプレビュー段階にあり、Gamma氏が言及したリポジトリ機能を有効にします。ただし、Codespacesは適切な機能を実現するまでに時間を要しています。
VS Codeの開発はMicrosoftが管理していますが、「毎月、GitHubのIssueに計画を投稿しています。誰でも見ることができます」とGamma氏は言います。「2011年以降、毎月リリースしており、継続的な進捗状況を示すリリースノートも毎月公開しています。」
今後の展開は？ Gamma氏によると、Pythonベースの統合型Jupyterノートブックへの注力は大きいとのことだ。Pythonの生みの親であるGuido van Rossum氏が昨年Microsoftに加わったことは、同社のこの言語サポートに悪影響を与えることはないだろう。イベント後半のPython関連のプレゼンテーションでは、Jupyterノートブック用の差分エディタが紹介されたが、これは素晴らしい機能のようだ。
何をすればよかったかと聞かれると、ガンマ氏は多くを語らなかったが、オープンソースプロジェクトとVS Code製品の命名が問題だと答えた。「[Google] Chromeの方がうまくやってくれました」と彼は言った。「彼らはChromeを製品として、Chromiumをオープンソースのコアとして使っています。混乱を招いています」。それは急いでいたためだと彼は言った。「VS Codeという名前が出てきたのは、出荷の5日前でした」
こうした命名上の混乱の裏には、より大きな問題が潜んでいます。VS Codeはコミュニティ向けのオープンプロジェクトなのか、それとも企業戦略を反映したMicrosoft製品なのか？現状ではその両方ですが、企業による所有権が一部の人々（EclipseのMilinkovich氏など）を不安にさせています。
成功した製品が古くなるにつれてしばしばダメージを受ける、肥大化をプロジェクトが本当に回避できるのかという疑問もあります。しかし、ソフトウェアパターンの知識とEclipseで何がうまく機能し、何がうまく機能しなかったかに関する経験を持つGammaは、この問題に対処する上で有利な立場にあります。Eclipse Foundationは、独自のTheiaプロジェクトという形でVS Codeに最大限の賛辞を与えてくれました。®
