Posté par arnaudus .
En réponse au journal [liens] Mais juste un.
Évalué à 2.
Dernière modification le 27 novembre 2017 à 13:42.
La thèse de l’article c’est que la complexité des spec des logiciels qu’on veut écrire dépasse la capacité d’un être humain à l’appréhender
Ce n'est pas vraiment ce que j'ai compris. Pour moi, l'auteur parlait des problèmes de la conception des logiciels. Typiquement, ça parle de code spagghetti, de variables qui sont accédées d'un peu partout, du fait qu'on n'arrive pas forcément à comprendre les implications du code qu'on a sous les yeux. Je n'ai peut-être pas vraiment compris, du coup, parce que pour moi, c'est avant tout un problème de conception du logiciel, de gestion de projet, et de compétence (voire de capacités) des programmeurs. C'est vrai que pour écrire du code, il faut parfois être très très concentré, ça peut demander un niveau d'abstraction assez profond, mais finalement pas beaucoup plus que pour écrire un roman avec beaucoup de personnages, ou de concevoir un objet industriel complexe. Et justement, la plupart des langages de programmation et de méthodes de programmation efficaces offrent des outils pour réduire cette complexité, de manière à ne travailler qu'avec des sous-parties indépendantes du logiciel. Ce n'est pas parce qu'un logiciel a 10M lignes qu'à chaque ligne de code on est susceptible de savoir ce qui se fait à l'intérieur de n'importe quel autre module. La programmation fonctionnelle, la programmation objet, ou simplement les bons comportements (encapsulation, pas de magic values, pas de variables globales, passage par valeur, pas de pointeurs nus...) permettent de grandement réduire la taille des sous-problèmes qu'on doit régler quand on code.
Après, je n'ai jamais participé à des projets gigantesques où la quantité de code était telle qu'il était humainement impossible d'avoir en permanence une représentation mentale de l'organisation complète du logiciel. J'ai toujours trouvé hallucinant la taille de certains logiciels, en me demandant s'il y avait en effet besoin d'autant de code pour effectuer des tâches qui n'apparaissaient pas comme si complexes que ça. Quand on dit qu'il faut 20M lignes pour coder le système de freinage et d'accélération d'une voiture, ça me semble assez dément. Comme ça a été dit plus haut, si tu as besoin de plusieurs centaines de lignes pour piloter un ascenseur, c'est que tu as un sérieux problème de design.
[^] # Re: Bof mouais pfff
Posté par arnaudus . En réponse au journal [liens] Mais juste un. Évalué à 2. Dernière modification le 27 novembre 2017 à 13:42.
Ce n'est pas vraiment ce que j'ai compris. Pour moi, l'auteur parlait des problèmes de la conception des logiciels. Typiquement, ça parle de code spagghetti, de variables qui sont accédées d'un peu partout, du fait qu'on n'arrive pas forcément à comprendre les implications du code qu'on a sous les yeux. Je n'ai peut-être pas vraiment compris, du coup, parce que pour moi, c'est avant tout un problème de conception du logiciel, de gestion de projet, et de compétence (voire de capacités) des programmeurs. C'est vrai que pour écrire du code, il faut parfois être très très concentré, ça peut demander un niveau d'abstraction assez profond, mais finalement pas beaucoup plus que pour écrire un roman avec beaucoup de personnages, ou de concevoir un objet industriel complexe. Et justement, la plupart des langages de programmation et de méthodes de programmation efficaces offrent des outils pour réduire cette complexité, de manière à ne travailler qu'avec des sous-parties indépendantes du logiciel. Ce n'est pas parce qu'un logiciel a 10M lignes qu'à chaque ligne de code on est susceptible de savoir ce qui se fait à l'intérieur de n'importe quel autre module. La programmation fonctionnelle, la programmation objet, ou simplement les bons comportements (encapsulation, pas de magic values, pas de variables globales, passage par valeur, pas de pointeurs nus...) permettent de grandement réduire la taille des sous-problèmes qu'on doit régler quand on code.
Après, je n'ai jamais participé à des projets gigantesques où la quantité de code était telle qu'il était humainement impossible d'avoir en permanence une représentation mentale de l'organisation complète du logiciel. J'ai toujours trouvé hallucinant la taille de certains logiciels, en me demandant s'il y avait en effet besoin d'autant de code pour effectuer des tâches qui n'apparaissaient pas comme si complexes que ça. Quand on dit qu'il faut 20M lignes pour coder le système de freinage et d'accélération d'une voiture, ça me semble assez dément. Comme ça a été dit plus haut, si tu as besoin de plusieurs centaines de lignes pour piloter un ascenseur, c'est que tu as un sérieux problème de design.