Feuille de route de la plateforme IntelliJ pour 2020
Nous souhaitons vous présenter quelques uns de nos travaux actuels pour l’amélioration d’IntelliJ IDEA et des autres EDI basés sur la plateforme IntelliJ. Les résultats de ces travaux seront disponibles cette année, pour certains d’entre eux dès la version 2020.1 qui sortira au printemps. Ils sont centrés sur deux objectifs principaux : les performances et la prise en charge des workflows de développement modernes.
Performances
Performances de l’indexation
Deux des principaux problèmes de performances de nos EDI concernent le démarrage (un outil qui prend beaucoup de temps pour démarrer est perçu comme lourd) et la vitesse d’indexation. Nous avons déjà beaucoup fait pour accélérer le démarrage l’année dernière, aussi cette année nous prévoyons de travailler plus sur les performances d’indexation.
Pour traiter ce problème, nous avons adopté une approche pluridimensionnelle. Tout d’abord, nous permettons d’utiliser des segments d’index préconstruits afin que chaque instance IntelliJ n’ait pas à faire le même travail d’indexation de la classe java.lang.String. Nous prévoyons de déployer la prise en charge progressivement au cours de l’année, en commençant par le JDK, puis en couvrant les bibliothèques de Maven Central, ainsi que les interpréteurs et les paquets dans d’autres EDI. Nous étudions également les moyens de prendre en charge le partage de blocs d’index pour le code source du projet au sein d’une équipe ou d’une entreprise, mais nous n’avons pas de plans spécifiques à ce stade.
Deuxièmement, nous prévoyons de réduire les perturbations de l’indexation en rendant beaucoup plus d’actions de l’EDI disponibles pendant cette opération.
Troisièmement, nous allons détecter les anomalies d’indexation, notamment les fichiers trop longs à indexer, les fichiers réindexés trop fréquemment et les reconstructions d’index provoquées par des exceptions, et vous en informer. Notre objectif est de fournir des étapes claires pour résoudre ces problèmes et d’améliorer les performances de nos EDI pour vos projets.
Et bien sûr, nous prévoyons d’investir dans de bonnes vieilles optimisations de performances pour nous assurer que le système d’indexation ne fait aucun travail inutile et ne consomme pas plus que nécessaire.
Remaniement du verrouillage en lecture/écriture du modèle de threading
Un autre problème majeur pour nos utilisateurs est le blocage de l’interface utilisateur. L’an dernier, nous avons construit une infrastructure permettant de signaler de tels blocages et apporté des modifications architecturales pour en corriger un grand nombre (par exemple, des écouteurs asynchrones pour les événements du système de fichiers). Au cours de cette année et des suivantes, nous prévoyons d’aller plus loin et de déplacer les actions nécessitant un verrouillage en écriture hors du thread de l’interface utilisateur.
Au tout début d’IntelliJ IDEA, une décision architecturale a été prise qui nécessitait que la plupart des opérations qui modifient les structures de données internes de l’EDI s’exécutent sur le thread de l’interface utilisateur. Cela concerne les actions de base (insertion d’un caractère dans un document) comme les opérations à grande échelle (changement de nom d’une méthode ayant des milliers utilisations). Cette architecture a l’avantage de simplifier le modèle de programmation, mais l’inconvénient évident est que la réactivité de l’interface utilisateur en souffre dans de nombreux scénarios.
Au fil des années, nous avons trouvé des moyens de contourner les limites de cette architecture, principalement en divisant les opérations de grande taille en plusieurs parties qui s’exécutent en arrière-plan et qui sont appliquées dans le thread de l’interface utilisateur. Une solution plus fondamentale consisterait à se débarrasser entièrement de l’exigence du thread de l’interface utilisateur, mais jusqu’à récemment, nous ne savions pas comment le faire sans une réécriture majeure de notre propre code et des plugins tiers. Nous avons désormais une solution architecturale qui permet une migration étape par étape, et nous avons commencé le travail d’implémentation.
Cette année nous allons refactoriser les composants essentiels de l’interface utilisateur et les API de la plateforme IntelliJ pour utiliser le nouveau modèle de threads. Lorsque le nouveau modèle sera stable et que l’amélioration sera perceptible, nous passerons au nouveau modèle dans tous les EDI pour rendre l’interface utilisateur plus réactive.
Chargement et déchargement des plugins sans redémarrage
Vous avez déjà eu un aperçu de cette fonctionnalité dans IntelliJ IDEA 2019.3, avec la possibilité d’installer des plugins de thèmes et des configurations clavier sans redémarrage. Dans la version 2020.1, nous prévoyons d’étendre cette prise en charge à tous les types de plugins. Nous prendrons en charge le chargement et le déchargement sans redémarrage pour un grand nombre de plugins groupés et nous fournirons des instructions de prise en charge aux développeurs de plugins tiers. À ce stade, l’avantage le plus important pour l’utilisateur consistera à pouvoir mettre à niveau les plugins en toute fluidité, sans avoir à redémarrer l’EDI.
L’objectif final de ce travail (pour les versions postérieures à 2020.1) est d’obtenir un EDI qui s’adapte à chaque projet que vous ouvrez. Le plugin Spring sera chargé uniquement pour les projets qui utilisent Spring, le plugin Angular uniquement pour les projets Angular, etc. Si vous n’utilisez pas une technologie, vous n’en verrez aucun élément dans l’interface utilisateur et ne subirez aucun impact sur les performances ou l’utilisation de la mémoire par le plugin prenant en charge cette technologie.
Prise en charge des workflows
Édition collaborative
L’édition collaborative est la fonctionnalité la plus demandée dans notre outil de suivi des tickets et nous sommes ravis d’annoncer que nous y travaillons. Dans l’approche que nous avons actuellement, il y aura un EDI principal, fonctionnant sur la machine où se trouve le code source, et les autres utilisateurs pourront connecter leurs EDI au principal en tant que “clients légers”, sans avoir besoin d’un accès direct au code source. Chaque utilisateur connecté aura son propre état (ensemble de fichiers ouverts, position du curseur, liste des variantes de saisie automatique, etc.), avec l’option de “suivre” un autre utilisateur s’il le souhaite.
Les utilisateurs du “client léger” auront accès aux principales fonctionnalités de l’EDI telles que la navigation, la saisie automatique et le débogage, mais pas à l’ensemble des fonctionnalités. (Par exemple, dans la version initiale, les clients légers peuvent ne pas être en mesure d’effectuer des opérations de contrôle des versions.) Notez que l’ensemble des fonctionnalités pour les clients légers n’est pas finalisé et nous ne pouvons donc pas encore dire si une fonctionnalité spécifique sera prise en charge ni à quel moment.
La prise en charge de l’édition collaborative s’appuie sur le protocole de Rider, il est donc très probable qu’elle sera initialement publiée dans Rider puis étendue à d’autres EDI. Dans tous les cas, ne vous attendez pas à en voir les résultats dès la version 2020.1 d’IntelliJ IDEA. Il s’agit d’un travail de plus longue haleine.
Notez également que notre approche actuelle de l’édition collaborative repose sur notre propre protocole et ne prend pas en charge l’interopérabilité avec des EDI extérieurs à JetBrains.
Nous envisageons la possibilité d’étendre l’approche du “client léger” à d’autres scénarios au-delà de l’édition collaborative, comme l’exécution du backend de l’EDI dans le cloud, mais nous n’avons pas encore de plans spécifiques dans ce domaine.
Prise en charge de l’exécution dans le cloud
Depuis un certain temps, de nombreux produits JetBrains prennent en charge l’exécution et le débogage de votre code sur des machines autres que la vôtre ou à l’intérieur de conteneurs. Toutefois, peu d’éléments étaient partagés entre les implémentations de ces fonctionnalités dans différents produits, et même les fonctionnalités de base telles que la prise en charge de Docker manquent de cohérence dans leur interface utilisateur.
Nous présentons maintenant un concept général d’environnement cible, qui fournit un moyen de copier des fichiers depuis ou vers celui-ci, et d’y démarrer des processus. Dans IntelliJ IDEA 2020.1, les environnements pris en charge inclueront votre machine locale, un conteneur Docker ou une machine connectée via ssh. Le choix de l’environnement cible sera initialement disponible pour les configurations d’exécution Java et Go.
Dans les versions ultérieures, nous prévoyons d’unifier notre prise en charge existante de Docker et des interpréteurs à distance autour de la nouvelle architecture. En plus de cela, nous fournirons une intégration approfondie avec le cloud, afin que vous puissiez indiquer que le processus doit s’exécuter sur une nouvelle machine virtuelle dans le cloud, sans préciser en détail à quelle machine se connecter.
Refonte du modèle de projet
Le modèle de projet est la facon dont l’EDI représente la structure de votre projet : quels fichiers appartiennent au projet, comment ils dépendent les uns des autres, quelles bibliothèques sont utilisées, etc. Le modèle de projet d’IntelliJ IDEA a bien servi au fil des ans, mais il comporte certaines limites. Tout d’abord, il ne prend pas en charge une combinaison arbitraire de projets de différents types. Par exemple, AppCode peut ouvrir un projet Xcode et Rider peut ouvrir une solution Visual Studio, mais il n’y a aucun moyen d’ouvrir un projet Gradle et un projet Xcode dans le même cadre d’EDI. Deuxièmement, le modèle de projet fonctionne au niveau des répertoires, pas des fichiers, et il ne peut pas représenter différents fichiers du même répertoire qui auraient des dépendances différentes. Cela rend difficile l’intégration de systèmes de construction tels que Bazel dans l’EDI et reste problématique dans d’autres scénarios.
Le modèle de projet remanié, que nous appelons en interne “modèle d’espace de travail”, supprimera ces limitations. Il apporte également des avantages supplémentaires avec une ouverture de projet accélérée, une synchronisation plus fluide avec Maven et Gradle et un modèle de programmation plus convivial. Nous allons commencer par basculer l’implémentation interne vers le modèle d’espace de travail. Une fois cette phase stabilisée, nous procéderons à l’ajout de fonctionnalités visibles par l’utilisateur comme la combinaison de projets de types arbitraires dans le même cadre d’EDI.
Résumé
Les projets décrits dans cet article ne représentent qu’une petite partie de ce sur quoi a travaillé notre équipe, et nous prévoyons de communiquer plus avant sur notre programme ultérieurement. Toutes ces informations peuvent être sujettes à modification et il est possible que certains des projets décrits ci-dessus n’aboutissent pas, mais nous avons encore d’autres idées intéressantes à proposer.
N’hésitez pas à nous faire part de vos réactions dans les commentaires ci-dessous. Nous vous informerons de la disponibilité de ces différents projets pour que vous puissiez les tester dans les prochaines annonces concernant le programme d’accès anticipé.
Bon développement !
Auteur de l’article original en anglais : Dmitry Jemerov
Subscribe to JetBrains Blog updates
