この記事の著者であるrebomixは、Microsoftの重要なオープンソースプロジェクトの一つであるVisual Studio Code（VS Code）のメンテナンスチームのメンバーです。彼はVS Codeのメンテナンスに関する自身の観察と考察を共有し、企業支援を受ける大規模なオープンソースプロジェクトがどのように運営されているかを垣間見せてくれます。

また、この記事により、VS Code 開発に興味を持ち、VS Code コミュニティ開発について学び、参加する中国国内のより多くの学生が利用できるようになることが期待されます。

Visual Studio Code を使い始めてほぼ1年になります。この機会に、このプロジェクトの開発とメンテナンスに関する私の経験をシェアしたいと思います。以下は私の個人的な見解であり、会社やチームを代表するものではありません。

プロジェクト

Visual Studio Code の目標は、拡張 API を使用して、ユーザーが VS Code で IDE に近い開発エクスペリエンス (効率) を実現できるようにする軽量エディターになることです。

しかし、VS Code については誤解している人が多いので、一つずつ説明していきたいと思います。

1. 「VS Code は VS によって作成されました。VS はそれを書き直すために人々のグループを雇い、多くの VS Code などを再利用しました。」

申し訳ありませんが、全く関係ありません。VS Codeのコアコード、つまりMicrosoft/monaco-editorは、2011年にErich Gamma氏がMicrosoftに入社した後に採用された「全く新しい」チームによって開発されました。Monacoエディターは元々ブラウザベースのエディターであり、当初はVisual Studio OnlineやOneDriveオンラインなど、様々なMicrosoftシステムに対応していました。この採用チームはErich氏にとって新しいものではありませんでした。メンバーのほとんどがIBMの元同僚で、中には20年以上も一緒にコーディングしてきた人もいたからです。

2. 「VS Code は Atom のクローンであり、Atom を大幅に改良したバージョンであり、Atom のテーマです。」

申し訳ありませんが、正確ではありませんが、少し繋がりがあります。数年間の成功の後、Monaco Editorはちょっとした暗黒時代に入りました。この頃、チームはMonaco Editorをデスクトップアプリケーションにする方法を研究し始めました。Atomと同様に、私たちが最初に注目したのはnode-webkitでした。node-webkitは業界に新風を吹き込み、無限の可能性をもたらしたと言っても過言ではありません。もちろん、最終的にはatom-shellを選択し、後にElectronへと発展しました。しかし、このatom-shellこそが、前述の誤解を引き起こした原因なのです。

***、もし起源を辿るなら、VS CodeはEclipseに遡るべきだ（同志諸君、なぜ皆背を向けているんだ？心配しないで、まだ話は終わっていない）。チームのコアメンバーは初期にErichと共に働き、Eclipseを開発する前にいくつかのエディタ/IDEを開発した。Eclipseの盛衰を目の当たりにしてきたからこそ、Monaco/VS Codeの設計には慎重だったのだ。拡張性は悪いのか？もちろん悪いが、Eclipseの欠点は既にいくつかの競合製品に現れている。

開発・保守

2013年にMicrosoftに入社してからMonacoを使い始めました。使用中にいくつか問題が発生したため、コードを研究し、いくつかの拡張機能を作成しました。その後、VS Codeが正式にオープンソース化され、Marketplaceでリリースされた後、プラグインの作成とプルリクエストの送信を始めました。昨年5月、チームと2週間ペアコーディングを行った後、VS Codeに入社しました。

VS Codeの開発はほぼ完全にオープンです。以前はUser Voiceを通じてフィードバックを集めていましたが、かなり前に廃止し、すべての問題解決はGitHubで行っています。年間/月間の計画はMicrosoft/vscodeのIssueとして提示されており、私の通常の開発ペースは次のとおりです。

プラン

前のマイルストーンが終了し、新しいマイルストーンが始まる前の週に、私は上司と、新しいマイルストーンに実装したい機能について、また休暇を取るべきかどうかについて話し合いました。

借金週間

新しいマイルストーンウィークは負債ウィークとして扱い、技術的負債の解消とプラグインへの小さな貢献に注力しています。私は通常、Vimプラグインと自作のRubyプラグインの開発に時間を費やしています。

発達

その後は2～3週間、通常の開発期間となります。毎朝、リストにある新しい問題をすべてトリアージする必要があります。緊急性の高い問題があれば、まずそれを解決しなければなりません。そうでない場合は、自分の機能の開発を続けます。

受信トレイの追跡

私がチームに参加した頃は、課題は1700件程度しかありませんでしたが、今では4000件を超えています（ほとんどが機能リクエストです）。このような状況ではGitHub Inboxは役に立ちません。私たちのやり方は、毎週GitHubで新しい課題を担当する同僚を置き、適切な担当者に割り当てることです。私はInbox Trackerを3回経験しましたが、本当にひどい状況でした。毎日、処理すべき課題が100件以上もあって、ベッドから出たくなくなるほどで​​す。

エンドゲーム

開発開始から最初の1週間、マイルストーン達成後、エンドゲームチームは新機能に関する様々なテストを実施し、そのマイルストーンで解決済みのすべての問題を検証します。すべてが完了すると、各メンバーは担当セクションのリリースノートを作成します。その後、エンドゲームマスターがバックエンドウェブサイトで新しい安定版をリリースします。

思い出に残るもの

「VS Codeは点滅カーソルのレンダリングのため、アイドル時にCPUの13%を消費した」という記述は実に的を射ています。VS CodeはElectronをベースにしており、ElectronはChromiumをベースにしています。このような場合、Chromiumのパフォーマンス問題の原因は、私たちが負わなければならないこともあります。

VS Code の編集領域はテキストエリアではなく、全てモック化されています。これは Ace、CodeMirror、Atom などで見られるように、主流の手法です。理由は単純です。トークン化、ハイライト、部分レンダリング、行折り返しを実装するには、レンダリングを自分で制御するのが最も便利だからです。テキストエリアをできるだけ忠実にシミュレートするために、カーソルをシミュレートしました。当初は、カーソルの動きを JavaScript で制御し、不透明度を調整していました。その後、コミュニティからプルリクエストが寄せられ、CSS アニメーションを使用して不透明度を調整できるようになりました。これは JavaScript 版よりも明らかにエレガントで、4～5 種類のカーソル移動オプションも提供しています。

しかし、ChromiumがCSSアニメーションに関してこれほど大きな落とし穴を抱えているとは誰が知っていたでしょうか？例えば、アニメーションの不透明度が1秒ごとに変化すると、Chromiumはページ上のアニメーションをリフレッシュレート（例：60Hz）に基づいて検出します。Chromiumの正確な動作は分かりませんが、16ミリ秒ごとにCPUとバッテリーリソースを少しずつ消費していることがわかります。

私たちにできることは全くありませんでした。ブロッコリーの作者であるジョー・リスが問題を送ってきて、Twitterで攻撃を仕掛けてきて、たちまち大きなニュースになったので、初めてこの問題に気づきました。ミゲル・デ・イカサでさえ気に入ってくれたほどです。本当に…

ちょうど夕食を終えたばかりでしたが、この問題は私の管轄範囲だったので、トラブルシューティングのために自分のパソコンを使う必要がありました。***結局、2年以上前から発生していたChromiumのバグであることが判明しました。Jo Lissには、責任は負わないが修正はすると伝えなければなりませんでした。

その結果、誰かがHacker Newsにこの情報をリークし、たちまち大きなニュースとなり、The Registerタブロイド紙にも掲載されました。デスクトップアプリケーションにブラウザ技術を使うことが正しい選択なのかどうか、誰もが議論を始め、議論は激化の一途を辿りました。

皆さんは議論して盛り上がっていましたが、私はここ数日、ジャンプカーソルとは何かを上司たちに説明するのに忙しく、まるで犬のように働きました。幸いにも、ChromiumのPMリーダーであるPaul Irishが、これはChromium側のバグだとコメントしてくれたので、一応の解決となりました。

異常な問題やPRはありますか?

1. 中国語で書かれた号の翻訳を誰に依頼すると思いますか?
2. PRを提出しても、私たちの提案を完全に無視し、独自に更新・修正する人がいます。そのようなPRはマージされる可能性は低いでしょう。しかし、私たちの丁寧な提案を単なるアドバイスとして真摯に受け止めてくれる人もいます…
3. バウンスカーソルについてもう一度言うと、これを考案したのはコミュニティの友人で、非常に巧妙な実装のように見えましたが、Chromium の落とし穴に陥るとは誰が予想したでしょうか...

中国語の文字に関する問題については、VS Code の貢献ガイドで非常に明確に説明されており、英語で質問するようアドバイスされています。しかし、中国語ユーザーが非常に多く、誰もが英語に苦労することもあるため、VS Code では中国語の質問が頻繁に寄せられています。私は次のような考えを持っています。

1. 私個人としては、GitHub が私たちのほぼ唯一のフィードバック チャネルであり、ユーザーが英語を知っていることを期待できないため、中国語で書くことは大きな問題ではないと考えています。
2. 中国語で書くことで確かに仕事量が増えたので、可能な限り英語で書くようにしています。
3. ただし、Google翻訳に本当に助けが必要だと感じる場合は、中国語で書いて私にCCすることをお勧めします。そうしないと、翻訳が誰にも理解できなかったり、誤解を招いたりする可能性があります。
4. 上司に、中国語の問題はタイトルに全てを詰め込み、説明欄が空欄になっていることがほとんどなのはなぜかと聞かれました。正直、どう答えていいのか分かりません。もし中国語で問題を書いていて、私にCCで送っていただけるなら、再現手順を一つ一つ中国語で分かりやすく説明していただけると助かります。そんなに難しいことではないですよね？
5. ステップ 4 を実行できず、それでも私が問題を解決できると期待する場合は、私にビールをおごっていただくことを検討してください。

人生

誰もがオープンソースを愛していますが、オープンソースへの貢献者のほとんどは自発的に活動しています。この観点から見ると、MicrosoftでVS Codeに取り組むことは、オープンソースコードの作成に対して誰かが報酬を支払ってくれるので、楽しい経験です。さらに、勤務時間中に特定のコードセットに取り組む必要がなくなりました。自宅でGitHubを閲覧しながら他のプロジェクトに取り組むことで、仕事中も仕事が終わった後も同じ空間を活用できます。

もちろん、デメリットも明らかです。仕事と生活を切り離すのは難しい場合が多いのです。仕事は週5日、1日8時間ですが、GitHubのIssueは24時間365日対応しています。難しい問題に直面すると、家に帰ってからも無視するのは難しいものです。しかし、このプロジェクトの特殊性ゆえに、私たちのチームには比較的良好なリモートワークと柔軟な勤務時間の文化が根付いています。