Author Archives: Masaru Horioka

こんにちは。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機能にアクセスできるわけではありません。 … Continue reading →