L'informatique malade des lignes de code

**Michel Rotta** · 16/02/2011, 00h54

L'informatique malade des lignes de code

ainsi va le titre d'un article de science et vie (02/2011 n°T02578).

J'ai récupéré quelques passages pour vous, je vous laisse lire l'article pour la totalité.

"... la capacité des informaticiens à construire des logiciels fiables et expurgés d'erreurs n'est jamais parvenue à suivre le rythme imposé (par la vitesse de progression du matériel)."

et d'expliquer que l'informatique omniprésente sur tous nos systèmes et objets multiplie les lignes de codes et donc la probabilité des bugs. Le plus grand risque étant constitué par la mise en réseau des objets dans un super internet.

Plus de 7000 langages de développement informatique ont été inventés et utilisés depuis que l'informatique existe. De ceux proches du code machine à ceux proches de la langue parlée. Le C restant le plus utilisé et un des plus subtil "... et, par conséquent, propice aux confusions."

Guillaume Brat, ingénieur logiciel à la Nasa dit : "Cette tâche (la vérification du code) occupe 88% de notre temps, le reste étant seulement dévolu à l'écriture du code"

Patrick Godefroid de Microsoft : "De manière générale, on observe sur les logiciels courants entre 1 et 10 bugs dans chaque millier de lignes de code". Imaginez le nombre de bug potentiels de nos systèmes d'exploitation super mastoc.

"Les erreur de programmation coûteraient 150 milliards de dollars par an uniquement en Europe."

De débattre sur les logiciels de vérification de non erreur dans le code basé sur une modélisation et sur des "méthodes formelles".

La fin de l'article appuie sur le risque constitués par la mise en réseau des objets intelligent (avec un logiciel embarqué) et les risques ingérables de bugs provoqué par des systèmes différents communiquant ensemble qui "... pourrait bien devenir le principal frein à ces avancées..."

**Marco46** · 16/02/2011, 10h02

C'est bizarre mais je suis pas du tout convaincu qu'il faille plus de lignes de codes qu'avant pour arriver au même résultat, bien au contraire. Plus le temps passe plus on a à disposition des API de toutes sortes qui mutualisent le code et les fonctionnalités et par la même les bugs ... Et plus le temps passe, plus on a à notre disposition des langages puissants et fiables.

Du coup, je comprends pas bien le reproche sur les bugs. A entendre l'auteur, on dirait vraiment que parce qu'il y a plus de logiciels, il y a plus de bugs et que c'est une régression.
Faisons un petit parallèle, il y a plus de voitures en circulation qu'il y a 20 ans donc fatalement il y a plus d'accidents. Ca veut pas dire que les voitures sont de plus mauvaise qualité.

Je vois pas le rapport entre la puissance du matériel et celui du nombre de bugs non plus.

Ça aussi c'est incompréhensible :

La fin de l'article appuie sur le risque constitués par la mise en réseau des objets intelligent (avec un logiciel embarqué) et les risques ingérables de bugs provoqué par des systèmes différents communiquant ensemble qui "... pourrait bien devenir le principal frein à ces avancées..."

Il parle de quoi, de bugs sur le client ? sur le serveur ? sur le protocole de comm ? Le protocole applicatif ? Ou d'un problème de conception ?
A le lire on dirait que les objets sont intelligents et du coup ils choisissent de parler à de nouveaux amis tous seuls.

Bref, science et vie ? Ouai ben pas très rationnel tout ça ...

**Michel Rotta** · 16/02/2011, 11h31

C'est sur que l'on a des fonctions de plus en plus puissantes pour développer. Reste que entre un windows 4 et un windows Seven (par exemple), le nombre de lignes de code de l'OS a cru considérablement.

Et que plus nos processeurs sont mutli-tâche et puissant, plus nous avons a produire un code capable d'exploiter ce fonctionnement en parallèle, ce qui est loin d'être à la portée du premier développeur venu. Dans tous les cas, je sais faire des trheads séparé pour des actions distinctes, mais je ne sais pas utiliser plusieurs flux dans un même process.

Pour la fin de l'article, c'est assez confus. En fait, ils expliquent (ce que je n'ai pas compris) que les lignes de codes des deux programmes pourraient ne pas faire la même chose (au même moment) et, de là, générer des problèmes. Je n'ai pas repris parce que j'ai trouvé cela un peu énorme. En effet, c'est faire une total abstraction de tout ce qui est protocole de communication chargé, justement, d'avoir une indépendance des codes.

Reste que quant tu vois comment ont été définis certains protocol, cela laisse parfois rêveur (cf : le rss).

**Nudger** · 16/02/2011, 12h01

Envoyé par Michel Rotta

Guillaume Brat, ingénieur logiciel à la Nasa dit : "Cette tâche (la vérification du code) occupe 88% de notre temps, le reste étant seulement dévolu à l'écriture du code"

L'exemple est atypique, la très grande majorité des compagnies peuvent se permettre une marge d'erreur. Pas la NASA car derrière ce sont des projets qui se comptent en centaines de millions de dollars et parfois il y a des vies humaines en jeu.

Envoyé par Michel Rotta

"Les erreur de programmation coûteraient 150 milliards de dollars par an uniquement en Europe."

La plupart des sociétés ne dépensent pas 88% de leur temps à vérifier le code. Mais si c'était le cas, ça serait intéressant de savoir si au final ça coûterais pas plus de 150 milliards de dollars ...

Bref, on mesure le coût du bug, mais on a tendance à oublier de mesurer et comparer le coût du contrôle du bug.

Acropole · 16/02/2011, 23h51

Plus de 7000 langages de programmation.
Ça montre bien que l'informatique patauge à la recherche de "quelque chose".

Pour le reste, les bugs sont plus dans la réflexion du programmeur que dans le code. 100% des problèmes informatiques se situent entre la chaise et le clavier, que ce soit la chaise de l'utilisateur, du programmeur ou de l'ingénieur en électronique.

**Paul TOTH** · 17/02/2011, 05h42

Envoyé par Acropole

Plus de 7000 langages de programmation.
Ça montre bien que l'informatique patauge à la recherche de "quelque chose".

ça montre surtout qu'il n'y a pas de réponse ultime (à part 42 évidemment).

Envoyé par Acropole

Pour le reste, les bugs sont plus dans la réflexion du programmeur que dans le code. 100% des problèmes informatiques se situent entre la chaise et le clavier, que ce soit la chaise de l'utilisateur, du programmeur ou de l'ingénieur en électronique.

parmis les 7000 langages il en existe tout de même quelques uns qui trimbalent quelques bugs dans la compilation ou l'interprétation du code du programmeur

... c'est donc à cause d'un autre programmeur

**ManusDei** · 17/02/2011, 09h22

En plus sur les 7000 langages de programmation, combien sont réellement utilisés ? Guère plus d'une centaine.

(sur les 7000, y a quand même des langages comme le Brainfuck et le Whitespace)

**Michel Rotta** · 17/02/2011, 10h04

A priori l'approche des 7000 langages comportes tous ceux inventés depuis la création de l'informatique qui ont pour une bonne part d'entre eux disparus.

Elle inclus également les langages spécialisé en industrie, j'ai appris dans cette article qu'il existe un langage spécial pour écrire les programmes qui tournent dans les voitures et un autre ceux qui tourne dans les avions...

Et je ne sais pas si ce chiffre inclus les versions (majeurs et/ou mineurs et/ou constructeur) des langages (par exemple, pour le basic il doit certainement y être référencé de nombreuses fois...)

**el_slapper** · 17/02/2011, 10h14

Et puis bon, les langages sont multiples parceque les problèmes à résoudre sont multiples. Je me voit mal faire une appli de compta bancaire en Flash, ou une animation internet en Cobol, pour prendre un exemple extrême.

Quand "au rythme imposé par les fabricants de matériel", je ne suis pas d'accord. Le matériel comme le logiciels sont tirés par la demande, qui est colossale. Des besoins nouveaux apparaissent sans cesse, et il faut fournir toujours plus de machines et de code pour y répondre.

Et les méthodes formelles, c'est bien gentil, mais quand on a un délai et des budgets réalistes, eh bien ça n'est pas possible. Déjà, ça implique qu'il n'y aie pas d'erreur dans les specs. Et là, je rigole. Parceque il n'est pas humainement possible de faire une spec sans erreur.

==>En bref, un article écrit par quelqu'un qui n'y connait rien. Si il est vrai que le code est de plus en plus présent(et les bugs qui vont avec), tout le reste n'est qu'approximations ou contresens. Beuh.

**omen999** · 17/02/2011, 10h25

Plus de 7000 langages de programmation.
Ça montre bien que l'informatique patauge à la recherche de "quelque chose".

alimenté aussi par tous les geeks moyens qui ont punaisé la photo de K Thompson et D Ritchie
au-dessus de leur lit et qui rêvent de voir graver leur nom dans le "hall of fame" du code

**Elepole** · 19/02/2011, 08h20

Envoyé par Marco46

Bref, science et vie ? Ouai ben pas très rationnel tout ça ...

Envoyé par Michel Rotta

Pour la fin de l'article, c'est assez confus. En fait, ils expliquent (ce que je n'ai pas compris) que les lignes de codes des deux programmes pourraient ne pas faire la même chose (au même moment) et, de là, générer des problèmes. Je n'ai pas repris parce que j'ai trouvé cela un peu énorme. En effet, c'est faire une total abstraction de tout ce qui est protocole de communication chargé, justement, d'avoir une indépendance des codes.

Envoyé par el_slapper

==>En bref, un article écrit par quelqu'un qui n'y connait rien. Si il est vrai que le code est de plus en plus présent(et les bugs qui vont avec), tout le reste n'est qu'approximations ou contresens. Beuh.

Faut pas oublier que Science et Vie est une revue de vulgarisation. Je viens de lire l'article en question (beh ouai, sa prend du temps pour arriver ici) Et bon .... c'est de la vulgarisation quoi !

Néanmoins ils ont pas tord sur le constat de base: plus le code est compliqué, lourd, et grand, plus y'a des risque de bug.

Acropole · 19/02/2011, 12h02

Envoyé par Elepole

Néanmoins ils ont pas tord sur le constat de base: plus le code est compliqué, lourd, et grand, plus y'a des risque de bug.

Oui mais parfois le code est bien plus compliqué que ce qu'il pourrait être. Certains sont spécialistes dans la construction d'usines à gaz, et pas forcément les moins diplômés et les moins expérimentés.
Keep it simple.

**Michel Rotta** · 19/02/2011, 15h00

C'est sur, il y a bien une règle de développement qui dit

Pourquoi faire simple et rapide alors que l'on peut faire long et compliqué.

.

**ManusDei** · 19/02/2011, 20h38

Faut bien justifier les frais, après tout

**Loceka** · 23/02/2011, 11h49

Je pense que si on passait plus de temps à vérifier le code et à éduquer (faire des retours sur le code vérifié, enseigner les bonnes pratiques) les développeurs et les architectes, il y'aurait beaucoup moins de bugs (dans un premier temps grace à la vérification, dans un second temps grace à ce qu'elle aura appris au dev, qui codera "mieux").

Par contre c'est sûr que les développements à proprement parler seraient plus long mais il y'aurait énormément moins de retours et de maintenance à faire.

Vu les atrocités que j'ai pu voir, tant en code pur qu'en conception (surtout en conception en fait), ce serait vraiment un gain de temps.

L'informatique malade des lignes de code

Discussions similaires

Partager

Partager