possiblité de changement... - Divers - Programmation
Marsh Posté le 18-08-2003 à 20:00:00
Cela n'engage que moi, mais à mon avis, ça va plutôt soit stagner, soit régresser, pas forcément pour les raisons que tu indiques, mais elles en font partie.
Règles :
Bon, c'est assez vague, mais y'a deux règles qui me viennent à l'esprit, qui sont toutes deux là pour améliorer la qualité et qui peuvent avoir l'effet inverse. Les règles de nommage pour commencer. Les règles de nommage, c'est très bien, et c'est très important. Seulement, que ce soit les entreprises ou les écoles, ou même les langages, chacun préconise sa propre sauce. Du coup, lorsqu'on pose côte à côte des lignes de code faites par deux personnes habituées à des règles de nomage différentes, non seulement on ne s'y retrouve plus, mais surtout on risque les confusion. Par exemple, pour moi, un élément écrit en majuscule avec des _ comme séparater de mots, c'est une constante. Pour certains, ce sera les instruction de pre-processeur, mais là encore ça va. Pour d'autre, ce sera les types... La tout de suite ça la fout mal si on confond une constante et un type...
Ensuite, les règles de programmation, par exemple pour gérer les exceptions. Certains vont préférer faire tous les tests et éviter les exceptions, d'autres vont préférer faire un try devant chaque block critique, tandis que d'autres font faire un try global à toute la fonction. Chaque système a ses avantages et ses inconvénients. Mais trop souvent, des personnes se disant que si ces trois règles existes, alors on peut les combiner. Et là c'est le début de la catastrophe.
- Pour les normes, le discours est assez similaire. Le principal problème réside au surnombre qu'elles représentent. Le principal risque à ce moment, c'est que les programmes soient incapable de communiquer car ils ont chacun fait des choix de normes qui ne se recoupent pas. Un nombre plus limité de normes, plus spécialisées, comme cela existait encore il y a quelques années était à mon avis un plus (mais il y avait aussi de grosses lacunes)
- L'UML, ouais. Le risque avec, tout comme avec Merise, c'est qu'on fasse un joli shémat beau avec des couleurs et tout. Et que vu que le schéma est joli et tient tout juste sur une feuille A4 en format paysage, on décide qu'il est parfait. Ca donne une fausse impression de sécurité. Certaines personnes vont bâcler leur travail sous prétexte que leur outil est parfait. M'enfin bon, ça c'est un cas à part, ça s'applique quelquesoit le domaine, et ça a toujours existé.
- Le CMM, je sais pas ce que c'est donc
- Sinon, le gros problème que je vois actuellement, pour ne parler que des écoles d'ingénieur françaises, et qui n'a aucun rapport avec les éléments indiqués dans le sujet, c'est qu'aujourd'hui (et depuis quelques années) il y a deux problèmes de fond qui se posent :
1) De plus en plus de personnes en sortent sans avoir aucune culture informatique. Ils ont fait une licence de bio, y'avait pas d'emplois à la sortie, ils se sont redirigés vers l'info... Leur bon niveau dans certaines matières à suffit à compenser certaines lacunes qui n'entre plus toujours en jeu lors des éxamens de sortie d'école. A partir de là, on voit tous le problème que ça peut poser.
2) Les écoles d'ingé, pour attirer le plus de candidats possible, cherchent à se démarquer des autres. Et comment ? En choisissant chacune des règles, en privilégiant telle norme, et telle méthode. On se retrouve alors avec sur le marcher avec des personnes de culture très différentes, qui posent tous les problèmes que j'ai cité dans les points précédents.
Donc non, je ne pense pas qu'il y ait une évolution positive à la clé, même si à la base c'est le but.
Marsh Posté le 18-08-2003 à 19:13:36
pensez-vous qu'avec tout ce qu'offre le génie logiciel: règle, norme, uml, cmm.... que la qualité des logiciels va augmenter avec le temps?
---------------
Borland rulez: http://pages.infinit.net/borland