En équilibre entre souplesse et respect des règles

Sans brider la créativité du programmeur, l'environnement de développement doit néanmoins maintenir la production du code dans les limites définies par l'entreprise. Il encadre aussi les tests et le suivi des différentes versions des applications.

Seul ou intégré dans une équipe nombreuse, le développeur a avant tout besoin d'un environnement qu'il reconnaisse, dans lequel il se sente à l'aise. Et ce confort tient souvent à des détails : la présentation du code source, les couleurs des commentaires, la largeur de l'indentation, la présence de boutons dans l'interface, la possibilité de personnaliser les menus, etc. La productivité du programmeur est directement influencée par l'ergonomie du logiciel qu'il utilise et ?" très important ?" par sa capacité à intégrer des fonctions. Avec son concept de plug in, Eclipse reste très souple, même si l'ajout des modules n'est pas toujours simple, ni leur qualité garantie. La rapidité ?" par exemple, sur les fonctions d'assistance à la saisie ou la vérification en temps réel du code ?" influe aussi sur la productivité globale.Dans le même ordre d'idées, la présence de mécanismes d'intégration ou d'une interface graphique souple fait gagner un temps précieux lors de la génération de séquences de code répétitives ou pour importer des fichiers existants. Mais cette automatisation ne doit être ni absolue ni systématique. Le développeur doit pouvoir reprendre manuellement chaque ligne et y apporter des modifications sans que cela obère le fonctionnement de l'environnement de développement intégré (EDI).

Garantir la conformité

Ce dernier doit également guider le programmeur dans la production d'un code propre et fonctionnel. Les environnements modernes incorporent des règles de codage (préfixes, règles de nommage, commentaires, etc.) et assurent l'analyse statique du code. Le plus souvent, ces fonctions s'appuient sur des fichiers de configuration en XML, que l'entreprise pourra adapter à ses besoins ou selon ses projets. Les tâches plus spécialisées, comme le refactoring (réécriture et optimisation du code sans modification de son comportement) ou l'analyse dynamique, sont souvent accessibles depuis l'EDI. Mais la génération de l'application requiert une machine dédiée particulièrement performante, à même d'accéder à tous les fichiers nécessaires. Et pour se montrer significatif, son test doit être réalisé dans un environnement proche de celui utilisé en production.Bien sûr, l'application elle-même et le langage employé, les disponibilités du réseau, du serveur ou de la base de données conditionnent directement les phases d'analyse poussée et de tests. Pour obtenir un tel environnement, le choix de l'EDI n'est pas anodin. Ainsi la souplesse reconnue d'Eclipse sur les plug in est-elle souvent citée comme un problème dans la définition et la configuration d'un environnement de tests. De ce point de vue, des EDI comme Windev ou la gamme des Visual Studio sont perçus comme beaucoup plus simples à mettre en ?"uvre. Et cela, parce qu'ils sont fournis avec l'ensemble de composants utiles et qu'ils prennent place dans un environnement balisé et connu. Mais il ne faut pas cantonner l'EDI à la seule production de code et aux tests. Le suivi des versions et son corollaire, la maintenance applicative, font également partie des fonctions qu'il doit, ou devrait, assurer ?" notamment dans le cadre de travaux collaboratifs. En pratique, ce sont plutôt des produits complémentaires qui se chargent de ces fonctions.L'EDI n'est plus un simple éditeur de texte avec un bouton pour lancer la compilation. Il est devenu l'outil principal de production du code. Et, à ce titre, il doit favoriser la productivité des collaborateurs. Mais il a aussi un rôle à jouer dans la standardisation, et donc la pérennité des sources et leur optimisation.