La qualité des programmes informatiques

Dans les années 1980, l’informaticien danois Bjarne Stroustrup (1950-) a conçu aux Bell Labs d’AT&T le langage de programmation C++, évolution du langage C (1972) vers l’orienté objet. Devenu dans les années 90 l’un des langages les plus utilisés, C++ sera l’ancêtre de Java (1995).

La MIT Technology Review a publié un entretien avec Stroustrup sur la qualité des programmes[1]. J’en condense ici en brassant le texte de l’entretien les éléments qui m’ont paru les plus instructifs. Le lecteur curieux pourra se reporter à l’original qui contient sur C++ des considérations que je n’ai pas reprises.

« Le meilleur programme écrit en C++ c’est Google, dont j’admire la performance et qui possède de splendides algorithmes parallèles et distribués. J’aime bien aussi les premiers navigateurs Web et les systèmes embarqués, comme les systèmes d’analyse de l’environnement et de pilotage autonome des Mars Rovers ou encore le contrôle des injecteurs dans les gros moteurs marins. Tout ces programmes sont conçus pour être fiables et répondre à de sévères contraintes de ressources. Il y a aussi du bon code dans Photoshop, qui gère de façon magnifique l’interface utilisateur et l’accès des algorithmes de traitement d’image aux pixels.

« Il existe donc d’excellents logiciels. Cependant la qualité moyenne des programmes est à pleurer. Leur structure est affreuse et il saute aux yeux que les programmeurs n’ont pas été attentifs à la cohérence, aux algorithmes, aux structures de données ni à la maintenabilité. Les utilisateurs ne peuvent pas s’en rendre compte parce qu’ils ne lisent pas le code : ils voient seulement les programmes se planter.

« Comme les programmeurs travaillent sous la pression de l’urgence, ils tentent d’accomplir des miracles en procédant par essais et erreurs, en utilisant la force pure et en faisant beaucoup de tests. Ils sont devenus experts dans l’art de construire, en intégrant des blocs non fiables, un système qui marchera à peu près. Le système évolue ainsi jusqu’à atteindre le niveau jugé acceptable mais il serait préférable de savoir pourquoi il fonctionne, et comment.

« La performance pose souvent problème : les programmeurs neutralisent les progrès du matériel en empilant dans leurs programmes couche sur couche d’abstractions compliquées, ce qui ralentit la réponse des interfaces ainsi que le démarrage et la fermeture des applications.

« Il est dangereux de considérer la programmation comme une tâche banale que pourraient remplir des programmeurs formés en quelques mois. Nous n’admettrions pas cela pour des plombiers, des comptables, des architectes, ni pour ceux qui conçoivent les ponts et les trains. Aujourd’hui trop de programmeurs n’ont pas été assez formés et manquent d’expérience.

« Évidemment il ne convient pas que les outils soient plus compliqués qu’il n’est nécessaire. Mais plutôt que de diminuer leur qualité pour satisfaire des gens qui peuvent à peine comprendre les problèmes et moins encore leur trouver de solution, il faut qu’ils puissent convenir au professionnel qualifié.

« On doit aussi construire des outils qui faciliteront les tâches simples pour davantage de gens, mais il ne faut pas laisser n’importe qui porter la main sur les infrastructures de notre civilisation technique, ni forcer les professionnels à utiliser des outils conçus pour les amateurs.

« En théorie, la solution réside dans la formation des programmeurs et l’utilisation de méthodes qui organiseraient la conception des produits en vue de leur utilisation à long terme et de leur maintenabilité. On devrait récompenser les réalisations solides et punir les négligences.

« Mais en fait on récompense les programmeurs qui produisent à la va-vite des programmes bogués et peu coûteux. Les utilisateurs veulent disposer de leurs gadgets sans devoir ni attendre, ni apprendre de nouvelles façons d’interagir avec leur ordinateur, ni payer pour la qualité. Si les utilisateurs ne changent pas de comportement, les fournisseurs ne modifieront pas le leur. En pratique, la solution théorique est donc inapplicable. On ne peut d’ailleurs pas arrêter un système d’information en attendant d’avoir tout reprogrammé.

« Continuer de la sorte est coûteux, dangereux et déprimant. Il faudrait un changement significatif et global, mais il ne pourra venir que de façon progressive.

« Trop de gens croient avoir trouvé la panacée dans une solution partielle : améliorer l’ingénierie des exigences, l’architecture, le langage de programmation, les tests, le système d’exploitation, le middleware, la structure des données, les algorithmes etc. Tout cela peut aider, mais si l’on croit qu’une de ces approches constitue la solution à l’exclusion des autres on va à l’échec.

« Je parie que le prochain grand progrès conceptuel concernera la gestion de la concurrence[2]. Alors que nos ordinateurs auront bientôt 32 processeurs, nous autres programmeurs n’avons pas encore assez réfléchi aux choses qui se passent simultanément.

« Je ne pense pas toutefois qu’un nouveau paradigme vienne remplacer d’un coup les paradigmes antérieurs : il s’y ajoutera. Ce qui viendra après la programmation orientée objet inclura l’orienté objet comme un sous-ensemble.

« Les sauts qualitatifs peuvent être très coûteux : je préfèrerais que le budget de la R&D fût consacré à des changements progressifs.

« Il faudrait aider l’évolution des langages et des bibliothèques avec des outils qui faciliteraient la mise à niveau des systèmes réels et permettraient aux anciennes applications de survivre dans l’environnement conçu pour le nouveau système.

« Qualifier avec arrogance les anciens programmes de legacy et recommander la stratégie qui consiste à tout réécrire, c’est inepte. J’accepterais des changements radicaux dans le code source si le changement était universellement supporté par un outil solide qui permette de traduire de l’ancien style vers le nouveau. En l’absence de tels outils, les développeurs de langages doivent être prudents envers les nouvelles possibilités, les développeurs d’application doivent être prudents envers les nouveaux outils offerts par les nouveaux langages.

« L’informatique et la programmation n’ont pas encore émergé comme fondations théoriquement et empiriquement solides pour développer des programmes répondant à de vrais problèmes. Théorie et pratique se rencontrent rarement : les chercheurs sont attirés par les problèmes théoriques plus que par les problèmes du monde réel, et beaucoup de programmeurs ignorent complètement les résultats de la recherche. »

[1] Jason Pontin, « The Problem with Programming », MIT Technology Review, 28 novembre et 7 décembre 2006, http://www.technologyreview.com/InfoTech/17831/ et http://www.technologyreview.com/InfoTech/17868/

[2] En informatique on nomme "concurrence" la situation où deux utilisateurs (ou deux processus informatiques) peuvent simultanément modifier les mêmes données. Le risque est alors que l'action de l'un efface l'action de l'autre (pensez par exemple au cas d'un document Word : la solution peut consister à enregistrer séparément chaque paragraphe et à émettre une alarme si deux utilisateurs veulent modifier le même paragraphe). La concurrence pose des problèmes difficiles aux applications transactionnelles.