IntelliJ Platform 2020年ロードマップ
こんにちは。JetBrains堀岡です。明けましておめでとうございます。
昨年（2019年）末にDmitry Jemerov（@intelliyole）より「IntelliJ Platform Roadmap for 2020（英語ブログ）」が発表されました。開発手法や開発環境のトレンドおよび変化に対応すべく、JetBrains製品を進化させるための様々な取り組みが紹介されています。
本稿は前記英文ブログポストを翻訳・補足したものとなります。
はじめに
IntelliJ IDEAおよびIntelliJプラットフォームベースのIDEを改善するための現在の取り組みの一部を公開したいと思います。これらの取り組みは、パフォーマンスと最新の開発ワークフローのサポートという2つの主要なテーマに集中しており、2020年中にリリースされる予定であり、一部は春の2020.1リリースに含まれる予定です。
パフォーマンスのさらなる改善
Indexing処理の効率化と改善
JetBrains IDEにおけるパフォーマンス関連の代表的な課題は、起動時のパフォーマンス（起動に時間がかかるツールは、全体的に動作重いと認識される傾向にある）とインデックス作成速度の2点です。2019年はIDEの起動をスピードアップするために多くのことを行ました。2020年はインデックス作成のパフォーマンス向上に注力します。私たちはこの問題に対して、以下に示す多面的なアプローチにより取り組んでいます。
最初の取り組みは、作成済みのインデックスチャンクを使用できるようにし、世の中のすべてのIntelliJインスタンスが（例えば）java.lang.Stringクラスのインデックス作成と同じ作業を行う必要がなくなるようにすることです。 まずJDKへの対応から始めて、次にMaven Centralに含まれるライブラリ、それ以降、IntelliJ以外のIDEで使用されるインタープリターとパッケージをカバーできるように、年間を通じて徐々にサポートを展開する予定です。加えて、チームまたは企業内でプロジェクトソースコードのインデックスチャンクの共有をサポートする方法を検討していますが、現時点では具体的な計画はありません。
第2の取り組みは、インデックス作成中により多くのIDEアクションを実行できるようにすることで、インデックス作成による待ちを少なくすることです。
第3の取り組みは、インデックス付けに時間がかかりすぎるファイル、頻繁に再インデックス付けされるファイル、例外によるインデックスの再構築など、インデックス付けの異常を検出して通知することです。この取り組みの目的は、問題を把握し、解決のための明確な手順を提供できるようにすることです。これによりプロジェクトごとに最適なIDEのパフォーマンスを向上させる手段を提供することを目指しています。
そしてもちろん、インデックスシステムが不要な作業を行わず、オーバーヘッドがないように、従来から継続的に取り組んでいるパフォーマンスの最適化にも取り組む予定です。
Read/Writeロック・スレッドモデルの再デザイン
JetBrainsユーザーにとってのもう1つの共通する課題は、UIのフリーズです。2019年では、このようなフリーズを報告するためのインフラストラクチャを構築しました（UIフリーズ時のログ自動生成）。報告された問題を手がかりに様々なアーキテクチャの変更を行い、多くのフリーズ問題を修正しました（例えば、ファイルシステムイベントの非同期リスナー）。2020年以降、さらに大きなステップとして、書き込みロックを必要とするアクションをUIスレッドから移動する予定です。 IntelliJ IDEAは、ごく初期の頃、IDEの内部データ構造を変更するほとんどの操作がUIスレッド上で実行されることを必要とするアーキテクチャを採用しました。これらの操作には、基本的なアクション（ドキュメントへの文字の挿入）と大規模な操作（1000箇所で使用されているメソッドの名前変更）の両方が含まれています。この初期のアーキテクチャの利点は、プログラミングモデルが単純になることです。一方で、明らかな欠点は、多くのシナリオでUIの応答性が低下することです。
過去数年にわたり、このアーキテクチャの制限を回避する方法として、大規模な操作を、バックグラウンドで実行される部分と、UIスレッドで実行される部分に分割する方法をとってきました。一方で、より根本的な解決策は、UIスレッドの要件を完全になくすことです。しかしながら、ごく最近までは、独自のコードとサードパーティのプラグインを大幅に書き直さずにこれを行う方法は存在しないと思われていました。この課題に対して、現在、私達は、段階的な移行を可能にするアーキテクチャ・ソリューションを考案し、それを実装する作業を開始しています。
2020年、IntelliJ Platformの重要なUIコンポーネントとAPIをリファクタリングして、新しいスレッドモデルを採用する予定です。新しいモデルが安定し、改善が認められるようであれば、すべてのIDEで新しいモデルに切り替えて、UIをスムーズでラグのないものにしたいと考えています。
再起動不要なプラグインのロードおよびアンロード
この機能については、IntelliJ IDEA 2019.3で部分的なプレビューを既に提供しており、再起動せずにテーマとキーマッププラグインをインストールできます。 2020.1では、このサポートを全てのタイプのプラグインに拡張する予定です。バンドルされているプラグインの大部分については、再起動なしでロードとアンロードをサポートします。サードパーティのプラグイン開発者向けに対しては、必要となるサポート手順を提供（日本語/英語）しています。この段階で最も重要なユーザーの利点は、IDEの再起動を必要としないシームレスなプラグインのアップグレードです。
一方で、この作業の（2020.1以降のバージョンにおける）最終目標は、開いているプロジェクトに対して適切なIDE機能のみを有効化することです。 例えば、Springプラグインは、Springを使用するプロジェクトに対してのみロードされ、Angularプラグインは、Angularプロジェクトに対してのみロードされるようになります。よって、プロジェクト内において特定のテクノロジーを使用しない場合、それに関連するUI要素は表示されず、そのテクノロジーをサポートするプラグインによるパフォーマンスやメモリ使用量への影響が無くなります。
新しいワークフローへの対応
Collaborative Editing（共同編集）
共同編集は、課題トラッカーで最も投票数の多いリクエストであり、2020年またはそれ以降に実現のために作業中であることをお知らせいたします。現在私達が実現しようとしているアプローチでは、ソースコードが配置されているマシン上でプライマリIDEが動作し、他のユーザーのIDEが「シンクライアント」としてプライマリIDEに接続します。（プライマリに）接続しているすべてのユーザーは、独自の状態（開いているファイル一覧、キャレットの位置、補完バリアントリストなど）を持ち、必要に応じて別のユーザーを「フォロー」するオプションがあります。
「シンクライアント」ユーザーは、ナビゲーション、補完、デバッグなどのコアIDE機能にアクセスできますが、全てのIDE機能にアクセスできるわけではありません。 （たとえば、初期バージョンでは、シンクライアントはバージョン管理操作を実行できない場合があります。）シンクライアントとしての完全な機能一覧は現時点では未定であり、どの機能がいつサポートされるかは回答することはできません。
共同編集のサポートはRiderプロトコルに基づいて実現される予定であるため、最初はRiderでリリースされ、その後、他のIDEに拡張される予定です。いずれにせよ、この方針による作業がIntelliJ IDEA 2020.1でリリースされることを期待しないでください。これは長期的な取り組みです。
また、共同編集に対する現在のアプローチは、独自のプロトコルに基づいており、JetBrains以外のIDEとの相互運用性をサポートしないことに注意してください。
「シンクライアント」アプローチを、クラウド上でIDEバックエンドを実行するなど、共同編集以外のシナリオに拡張する可能性を検討していますが、その分野での具体的な計画を発表する準備はまだできていません。
Cloud Execution Support（IDE間で共通なターゲット環境という概念の導入）
これまで、多くのJetBrains製品が、リモートマシンまたはコンテナ内でのコードの実行とデバッグをサポートしてきました。ただし、異なる製品間で、これらの機能の実装はあまり共有されておらず、Dockerサポートなどの基本的な機能でさえ、一貫性のないUIを持っています。
この課題に対して、今回、（JetBrains製品に共通な）ターゲット環境という一般的な概念を導入します。これにより、IDEとターゲット間でファイルをコピーする方法や、IDEからターゲット上でプロセスを開始する機能を提供します。 IntelliJ IDEA 2020.1では、（ターゲットとして）サポートされる環境には、ローカルマシン、Dockerコンテナ、またはsshで接続されたマシンが含まれます。ターゲット環境の選択は、最初はJavaおよびGoの実行構成(Run Configuration)でのみ利用できる予定です。
2020.1以降のリリースでは、既存のDockerとリモートインタープリターのサポートを新しいアーキテクチャに統合する予定です。それに加えて、より深いクラウド統合を提供する予定です。接続する特定のマシンの詳細を指定することなく、プロセスをクラウド内の新しいVMで実行する必要があるケースに対応することがゴールです。
プロジェクトモデルの再デザイン
（IntelliJプラットフォームにおける）プロジェクトモデルは、IDEがプロジェクトの構造をどのように表現するかを示すものです。どのファイルがプロジェクトに属するか、どのファイルが互いに依存するか、どのライブラリが使用されるかなどです。 IntelliJ IDEAのプロジェクトモデルは長年にわたって役立ってきましたが、一定の制限があります。まず、異なるタイプのプロジェクトの任意の混合をサポートしていません。たとえば、AppCodeはXcodeプロジェクトを開き、RiderはVisual Studioソリューションを開くことができますが、GradleプロジェクトとXcodeプロジェクトを同じIDEフレームで開く方法はありません。次に、プロジェクトモデルはファイルではなくディレクトリのレベルで動作するため、同じディレクトリ内の異なるファイルが異なる依存関係を持つことを表すことはできません。これにより、BazelなどのビルドシステムをIDEに統合することが難しくなり、他のシナリオでも課題が生じます。
この課題に対して、我々が内部的に「ワークスペースモデル」と呼ぶ再設計されたプロジェクトモデルでは、これらの制限が取り除かれます。また、プロジェクトを開く際のパフォーマンスの向上、MavenおよびGradleとのスムーズな同期、より優れたプログラミングモデルなどの追加の利点ももたらします。我々は（ユーザーには見えない）IDEの内部実装をワークスペースモデルに変更することから作業を始めます。これが安定したら、同じIDEフレームで任意のタイプのプロジェクトを統合するなど、ユーザーに見える機能の実装に進む予定です。
サマリー
この投稿で説明した取り組みは、チームが取り組んでいる作業のほんの一部に過ぎません。ホリデーシーズンの後、計画に関する詳細情報を公開する予定です。もちろん、これらはすべて変更される可能性があり、上記の作業の一部がリリースされない可能性は十分にありますが、そのときは、代わりに別の素晴らしい機能を提供する予定です。
ロードマップについて、皆様からコメントをお待ちしております。また、新たな取り組みの一部をお試し頂ける準備ができたことをお知らせするアーリーアクセスプログラムの発表にも今後ご注目ください！
Happy Developing!
Subscribe to JetBrains Blog updates
