Quand les IDEs deviendront plus intelligents que nous...

Under the right circumstances, groups are remarkably intelligent and are often better than the smartest person in them.
– James Surowiecki: Wisdom of the Crowds

Les équipes de la fondation Eclipse se sont lancées dans un nouveau projet des plus ambitieux : comment rendre les IDEs plus "intelligents"?

Au début de cette réflexion, vient l'analogie avec le web lui-même. Qu'est-ce qui l'a rendu plus "intelligent" ces dernières années? L'aspect communautaire, collaboratif, l'interconnexion des données, l'apprentissage des usages... En somme, le web 2.0. Ainsi viennent de naitre les IDE 2.0!

Pour commencer, un graphique qui permet de résumer l'essentiel de cette idée :

Le but est donc de centraliser les informations sur les usages courants des utilisateurs au sein des IDEs afin d'améliorer leur analyse du code en cours d'écriture. C'est un apport considérable en termes d'aide au développement, tous points confondus :

Recommandations de code

Lors de l'utilisation de l'auto-completion, il est souvent ennuyeux de voir apparaître une liste barbante exhaustive de TOUTES les méthodes disponibles sur l'objet (provenant de l'héritage, du framework...). La fonctionnalité de recommandation de code va permettre de n'afficher, dans un premier temps, qu'un ensemble de méthodes pertinentes, selon le contexte courant et l'usage qu'en ont fait d'autres développeurs dans le même contexte :

Moteurs de templates intelligents

Poussons cette première idée encore plus loin : pourquoi simplement s'arrêter à la suggestion de méthodes quant il même possible de présenter des blocs de codes entiers couramment utilisés et répondant aux mêmes contraintes de contexte? C'est également possible avec ce nouveau système de templates, inférant l'usage le plus judicieux compte tenu du code déjà en place :

JavaDoc étendue

Tout le monde s'accordera sur le fait qu'il est assez fastidieux de rédiger la JavaDoc correspondante au code mis en place... Quand elle existe, elle est parfois peut détaillée ou peu explicite. De plus, dans le cas de la surcharge simple d'objets d'un framework, elle peut s'avérer peu pertinente. Alors plutôt que de ne s'appuyer que sur ce que les utilisateurs saisissent explicitement, pourquoi ne pas se baser directement sur leurs usages du code pour fournir une doc plus pertinente? C'est ce que fait cette nouvelle JavaDoc étendue :

Détection de bug intelligente

Dans le même principe que pour la JavaDoc, il est envisageable que l'IDE propose un ensemble de solutions à certains problèmes grâce à une analyse du code basée sur la recherche de différences avec des blocs de codes couramment utilisés (appels de méthodes manquants, manipulations d'objets incongrues...) :

Et ce, à l'exécution ou durant le développement :

Recherche de code intégrée

Certains sites comme Google Code Search ou Koders mettent en ligne des extraits de code dans le but de faciliter les recherches lorsqu'il s'agit de trouver, par exemple, comment accéder à certains objets d'un framework lors d'un développement spécifique. Leur principal inconvénient est justement de ne pas être intégrés aux IDEs. Problème une nouvelle fois résolu avec cette nouvelle fonctionnalité :

Recherche de piles d'erreurs

Dans la même lignée que la fonctionnalité précédente, il pourrait être intéressant de disposer d'un référentiel de piles d'exceptions qui permettrait, grâce à une recherche à partir d'une trace, de trouver un ensemble d'extraits de code ayant permis de la résoudre. Voici par exemple l'idée soulevée :

En résumé

Comme vous pouvez le constater, ce nouveau projet de la fondation Eclipse, "Eclipse Code Recommenders", fourmille d'idées ingénieuses et révolutionnaires qui vont à coup sûr modifier notre vision actuelle du développement : il ne s'agira plus de coder tout seul dans son coin et, dans le meilleur des cas, de publier ses solutions au sein de communautés, mais ce seront les usages de ces communautés qui permettront à chacun d'améliorer son travail... Que de perspectives intéressantes!

Sources :


Fichier(s) joint(s) :

1 commentaires: