Inscrivez-vous gratuitement à la Newsletter BFM Business
Automatiser de nombreuses tâches réduit les risques d'erreurs et facilite la génération et le déploiement des applications. En conséquence, le développeur s'éloigne peu à peu de la technique vers le métier.
La performance d'un environnement de développement intégré (EDI) ne se juge plus à présent sur la seule satisfaction des programmeurs ou la quantité des codes sources produits. En effet, les applications devenant de plus en plus
complexes ?" tant dans les fonctions que pour le nombre d'ingénieurs impliqués sur les projets ?", les contraintes initiales de propreté, d'efficacité et de conformité du code source produit laissent place à des préoccupations plus
financières : respect des budgets et du calendrier.De fait, les EDI récents automatisent de plus en plus la génération du code répétitif ?" notamment dans les appels à l'infrastructure ou au middleware. Cette évolution est surtout visible par la disponibilité quasi
systématique d'outils de modélisation de type UML, mais aussi par le nombre et la diversité des connecteurs supportés. Ce point apporte deux nouveautés fondamentales. D'une part, une fraction de plus en plus importante du code utilisé est issue des
bibliothèques fournies par l'éditeur de l'EDI. D'autre part, le développement devient plus collaboratif et orienté métier.
L'automatisation crée de la standardisation
Le fait que les EDI récents assurent une part croissante de la production du code procure des avantages et des inconvénients. Les algorithmes de génération de code source ?" qu'ils soient intégrés à l'EDI ou utilisés par
l'éditeur lors de la construction de ses bibliothèques ?" sont assez performants pour éradiquer les erreurs les plus communes. En outre, comme ce code source produit concerne surtout la connexion à l'infrastructure ou l'intégration dans le
framework global de l'application développée, il exempte le développeur de la partie la moins intéressante de son métier ?" et la plus génératrice d'erreurs. Le département d'ingénierie logicielle de l'université de Carnegie Mellon évalue que
les EDI ne produisent qu'une erreur pour 1 000 lignes de code, contre une pour 10 lignes lors d'une saisie manuelle.Le code ainsi généré présente néanmoins deux inconvénients. Premièrement, destiné à un usage universel, il n'est pas optimisé en fonction d'une application ou d'une architecture particulière. De plus, il se révèle généralement
assez peu intelligible. Il est même déconseillé de le modifier, sous peine d'annuler les bénéfices que l'EDI lui fournit automatiquement, notamment en termes de maintenance. Le risque apparaît donc de perdre les gains de temps réalisés avec le
codage automatisé lors de la mise au point ou de l'optimisation. Secondement, il semble relativement naturel que, se reposant de plus en plus sur ces codes source, les développeurs les connaissent moins bien que s'ils les avaient produits eux-mêmes.
Et cette méconnaissance nuit à l'optimisation ou à l'adaptation pour répondre à une contrainte métier ou système.Mais telle est la rançon de la course à la productivité. Le plus important pour l'entreprise est qu'elle accepte sciemment d'utiliser un code qu'elle ne maîtrise plus en totalité et de se soumettre à lui. Dans une étude sur les
outils intégrés, Gartner signale d'ailleurs que les sociétés doivent prendre en compte le coût de la maintenance applicative, qui croît selon le niveau d'intégration des outils. Mais cette démarche n'apparaît pas nouvelle en matière d'informatique.
Toutes les entreprises s'appuient sur des systèmes d'exploitation, des bases de données, et des infrastructures qu'à un certain niveau elles ne dominent pas.La disponibilité des outils de modélisation et l'intégration de fonctions de travail collaboratif changent le rôle du développeur. En favorisant le partage de l'information entre les équipes impliquées sur le projet, les EDI
accélèrent et fédèrent les travaux de chacun. Les programmeurs ne sont plus seulement chargés de créer qui un module, qui une routine. Ils participent à l'ensemble du projet. Et posséder une visibilité croissante sur toute l'application projetée et
ses composants, sur l'architecture globale et les systèmes mis en ?"uvre, influe nettement sur la façon d'exercer le métier.
Relancer la production de valeur ajoutée
Ce partage de l'information et la participation interactive de chacun à la tâche d'ensemble donnent aux développeurs de la visibilité sur les autres. Ils sont ainsi en mesure de se positionner pour, quasiment en temps réel, se
concentrer sur telle ou telle tâche susceptible de faire avancer le projet ?" par exemple, le lancement de procédures de tests plus larges. De plus, en sachant ce que font les autres, non seulement les développeurs bénéficient immédiatement
des parties disponibles, mais ils sont aussi informés des éventuelles modifications ou nouvelles options prises. Le programmeur n'est plus isolé. Il s'intègre vraiment dans une démarche industrielle.En complément, l'automatisation d'un grand nombre de tâches répétitives dégage du temps, mais surtout une part significative de l'intelligence disponible, pour des tâches à forte valeur ajoutée. Les exemples abondent de
développeurs qui se redécouvrent une passion pour leur métier. Les fonctions d'automatisation des EDI ne se limitent pas à la simple génération ou à la validation du code. Une kyrielle de contrôles des versions et de la cohérence avec les
middlewares ou les systèmes décharge désormais les informaticiens de travaux fastidieux et délicats. C'est également le cas pour l'élaboration des exécutables et leur déploiement sur les serveurs, réalisés automatiquement à partir de scripts.
Scripts dont la génération, la modification ou le paramétrage sont directement renseignés par les EDI en fonction de l'état d'avancement des travaux de chaque développeur.
