Aujourd'hui, nous aimerions parler de certains des projets en cours de l'équipe de la plateforme IntelliJ qui affecteront IntelliJ IDEA et d'autres IDE basés sur notre plateforme. Les résultats de ces projets seront publiés au cours de la prochaine année; Certains d'entre eux seront déjà dans la version 2020.1, qui sortira au printemps. Les projets dont nous aimerions parler concernent deux grands domaines: la productivité et le soutien aux scénarios de développement modernes.
Performances
Vitesse d'indexation
L'indexation à l'heure actuelle est l'un des endroits les plus problématiques avec les performances de nos IDE. Nous prévoyons d'aborder sa solution dans plusieurs directions.
Premièrement, nous prévoyons de prendre en charge des
fragments d'index prêts à l'
emploi . Maintenant, au lieu de chaque copie IntelliJ IDEA réindexant la classe java.lang.String, nous pouvons fournir un fragment d'index prêt à l'emploi pour le JDK à télécharger, qui peut être réutilisé sans frais de processeur supplémentaires. En plus du JDK, nous explorons la possibilité de fournir des fragments d'index prêts à l'emploi pour les bibliothèques de Maven Central, ainsi que pour les interprètes et les packages dans d'autres IDE. Nous aimerions également permettre aux équipes et aux organisations d'utiliser des fragments d'index prêts à l'emploi pour le code de leurs projets, mais nous n'avons pas encore de plans concrets pour cela.
Deuxièmement, nous prévoyons de rendre l'indexation
moins gênante pour le travail en rendant un plus large éventail d'actions disponibles pendant l'indexation.
Troisièmement, nous prévoyons de détecter
les anomalies d'indexation et d'en informer les utilisateurs. Les anomalies incluent les fichiers qui sont indexés trop longtemps ou trop souvent, ainsi que les reconstructions d'index provoquées par des exceptions. Notre objectif est de proposer des étapes concrètes pour résoudre le problème et améliorer les performances de l'IDE.
Et enfin, nous continuons à gérer la bonne vieille optimisation - pour nous assurer que les index n'obtiennent pas de données inutiles et que le processus d'indexation utilise les ressources minimales possibles.
Nouvel accès multithread aux structures de données IDE
Un autre point problématique des performances est le gel de l'interface utilisateur. Cette année, nous avons construit une infrastructure pour recueillir des informations sur ces problèmes. Cela nous a permis de résoudre bon nombre d'entre eux (par exemple, nous avons créé et utilisé un mécanisme standard pour le traitement asynchrone des événements du système de fichiers). L'année prochaine, nous prévoyons d'aller plus loin et de supprimer les
opérations qui modifient les structures de
données du flux d'interface utilisateur.
À l'aube d'IntelliJ IDEA, une décision architecturale a été prise qui a exigé toutes les modifications des structures de données IDE du flux d'interface utilisateur. Cela inclut à la fois des actions de base (insertion d'un caractère dans un document) et de longues opérations (changement de nom d'une méthode appelée depuis de nombreux endroits). Cette architecture simplifie grandement le modèle de programmation, mais dégrade évidemment la réactivité de l'interface.
Au cours des dernières années, nous avons en quelque sorte appris à contourner les limites de ce modèle, principalement en raison du fait que nous divisons les opérations longues en calcul de fond des modifications nécessaires et, dès que possible, appliquons ces modifications dans le flux d'interface utilisateur. La solution idéale serait de supprimer complètement l'exigence de faire quelque chose dans le thread d'interface utilisateur, mais jusqu'à présent, nous n'avons pas compris comment cela peut être réalisé sans réécrire l'intégralité du code IDE et des plugins tiers. Nous avons maintenant une option d'architecture qui nous permet de migrer progressivement le code vers un nouveau modèle multithreading, et nous commençons à travailler sur sa mise en œuvre.
Au cours de la prochaine année, nous prévoyons d'ajouter la prise en charge du nouveau modèle multithreading aux composants d'interface utilisateur clés et aux API de plate-forme. Lorsque nous verrons que le nouveau modèle fonctionne de manière stable et donne les améliorations attendues, nous passerons à lui et nous débarrasserons ainsi de la principale source de problèmes avec le gel de l'interface utilisateur.
Téléchargez et déchargez les plugins sans redémarrer
Les premiers résultats des travaux dans ce sens étaient déjà dans
la version 2019.3 , qui vous permet d'installer des plugins pour les thèmes de couleurs et les dispositions de clavier sans redémarrer. Dans la prochaine version, nous prévoyons d'étendre ce support à tous les types de plugins. Nous prendrons en charge le chargement et le déchargement sans redémarrage pour la plupart de nos propres plugins, et nous avons publié
des instructions de support pour les rédacteurs de plugins tiers.
À ce stade, le principal avantage sera une mise à jour du plug-in indolore qui ne nécessite pas de redémarrage. À l'avenir, nous prévoyons d'atteindre un objectif plus intéressant: un IDE qui télécharge automatiquement uniquement l'ensemble de plug-ins nécessaire pour chaque projet que vous y ouvrez. Utilisez Spring - le plugin Spring se charge, vous avez besoin d'Angular - le plugin est à votre service. Les plugins inutilisés seront automatiquement désactivés et ne consommeront pas de ressources et n'occuperont pas d'espace dans l'interface.
Prise en charge des scripts de développement
Édition collaborative
La demande de support de coédition a recueilli le plus de votes dans notre outil de suivi des problèmes, et nous sommes heureux d'annoncer que nous travaillons sur cette fonctionnalité. Dans notre approche actuelle, l'IDE «principal» fonctionnant sur la machine où le code source édité est stocké et les «clients légers» qui peuvent se connecter à l'IDE principal et n'ont pas besoin d'avoir leur propre copie du code source sont distingués. Chacun des clients connectés a son propre état (un ensemble de fichiers ouverts, une position de chariot, une liste d'options de complétion automatique, etc.), mais il peut également «suivre» un autre utilisateur si vous le souhaitez.
Les clients légers auront accès aux fonctionnalités de base de l'EDI, telles que la navigation, l'auto-complétion et le débogage, mais ne prendront pas en charge 100% des fonctions disponibles. (Par exemple, l'utilisation des systèmes de contrôle de version n'est pas incluse dans le plan actuel de la version initiale.) L'ensemble exact des fonctions prises en charge n'est actuellement pas défini et nous ne sommes pas prêts à répondre aux questions sur ce qui sera pris en charge et quand.
La prise en charge de la coédition est basée sur le protocole
Rider , il est donc très probable qu'elle apparaisse initialement dans ce produit puis se propage à d'autres IDE. Dans tous les cas, rien de tout cela n'apparaîtra dans la version IntelliJ IDEA 2020.1 - il s'agit d'un plan pour une période plus longue.
De plus, il convient de noter que, puisque l'implémentation de coédition actuelle utilise notre propre protocole, elle ne sera pas compatible avec les outils non JetBrains.
L'approche client léger peut être utile pour d'autres scénarios, tels que le déplacement du backend IDE vers le cloud, mais nous ne sommes pas prêts à annoncer des plans dans ce domaine.
Prise en charge du lancement dans le cloud
Depuis un certain temps maintenant, beaucoup de nos produits prennent en charge l'exécution et le débogage de code sur des ordinateurs distants et dans des conteneurs. Malheureusement, cette prise en charge est presque partout implémentée à sa manière, et même des fonctionnalités universelles telles que la prise en charge de Docker sont différentes selon les différents IDE.
Maintenant, nous ajoutons au niveau de la plate-forme le concept «d'environnement d'exécution», qui fournit un moyen de copier des fichiers vers ou depuis celui-ci, ainsi que de démarrer des processus. Dans IntelliJ IDEA 2020.1, nous prenons en charge l'exécution sur la machine locale, dans le conteneur Docker et via une connexion ssh. Vous pouvez choisir l'environnement à exécuter dans les configurations de lancement pour Java et Go.
Dans les versions futures, nous prévoyons d'unifier la prise en charge de Docker et des interprètes distants en fonction de la nouvelle architecture. De plus, nous offrirons une meilleure intégration avec les clouds afin que vous puissiez démarrer le processus sur une nouvelle machine virtuelle dans le cloud sans spécifier l'adresse spécifique de la machine à laquelle vous souhaitez vous connecter.
Nouveau design de modèle de conception
Le modèle de projet est la façon dont l'EDI représente la structure de votre projet: quels fichiers s'y rapportent, comment ils dépendent les uns des autres, quelles bibliothèques sont utilisées, etc. Le modèle de conception IntelliJ IDEA nous a bien servi au fil des ans, mais nous avons commencé à rencontrer ses limites. Premièrement, il ne permet pas de mélanger au hasard des projets de différents types. Vous pouvez ouvrir un projet Xcode dans AppCode ou des solutions Visual Studio dans Rider, mais il n'y a pas un tel IDE dans lequel vous pouvez ouvrir des projets Gradle et Xcode dans une seule fenêtre. Deuxièmement, il fonctionne au niveau du répertoire et ne permet pas à différents fichiers dans le même répertoire d'avoir des dépendances différentes. Cela complique l'intégration avec des systèmes de construction comme Bazel et crée des problèmes dans d'autres scénarios.
Le nouveau modèle de conception, que nous appelons le modèle d'espace de travail, supprime ces limitations. Il offre d'autres avantages, tels qu'une ouverture de projet plus rapide, une synchronisation plus fluide avec Maven et Gradle et un modèle de programmation plus pratique.
Nous commencerons par transférer l'implémentation des fonctions existantes vers un nouveau modèle de projet, puis, lorsque tout fonctionnera de manière stable, nous commencerons à ajouter de nouvelles fonctions, telles que l'ouverture d'un ensemble de projets de différents types dans une seule fenêtre IDE.
Résumé
Ce dont nous venons de parler n'est qu'une petite partie de ce sur quoi l'équipe travaille, et nous prévoyons d'en dire plus sur nos plans après les vacances. Bien sûr, tous ces plans peuvent changer, et il se pourrait très bien qu'une partie de cette histoire ne soit jamais publiée, mais nous apporterons d'autres améliorations intéressantes pour vous.
Nous nous réjouissons de vous entendre. De plus, nous vous invitons à participer à notre programme d'accès anticipé, qui vous donnera la possibilité d'essayer certaines de ces fonctionnalités avant qu'elles ne soient publiées.