> Aujourd'hui les écoles forment plus à "pisser" du code. En tant que chef > d eprojet informatique, j'ai très souvent vu de jeunes diplômés coder > sans penser ni au test ni à la traçabilité par exemple. Encore moins à > la réutilisation du code aussi. Je ne parle pas des commentaires et de > la documentation. > > Ce qui fait la qualité de l'enseignement de la programmation, ce st > aussi que l'enseignant sachent ce que veut dire faire du développement > de façon professionnelle, ce qui n 'est pas toujours le cas (encore > qu'il serait pourtant facile de penser qu'avec le temps de plus en plus > d 'enseignant aient eu une carrière préalable ailleurs que dans > l'enseignement). >
Peut etre le probleme est que de nos jours les jeunes ont tous a 15 ans leur ordinateur et font de la bidouille "programmatoire". Les écoles et les étudiants ont donc tendance a vouloir se démarquer des gens n'ayant pas ( encore ) le diplome par la methodologie et les bonnes pratiques. Du coup i) on est passé par dessus beaucoups de choses interréssantes ii) Si les bonnes pratiques sont respectées alors l'unicité de pensée fait que le code est toujours lisible et de qualité iii) si il y a du vieux ca merde et ca n'est pas de leur faute iii-bis) si les modules tierce partie merdent ca n'est pas de leur faute. Le pire dans tout ca c'est que lorsque les bonnes pratiques ne sont pas possibles pour des raisons de performance ou de deadline, ils se croient tout permit ( notement car ils n'ont pas appris autre chose ) et font les pires conneries. Des bonnes pratiques d'il y a 15 ans ont été déja oubliées ( ex. prendre des valeurs numériques dans la doc et les copier coller dans le code au lieu de les recopier, ex. 2 : ne jamais changer le sens d'une variable, il il y a maintenant un deuxieme cas de figure, remplacer la déclaration de myvar en myvar1 et myvar2 plutot que d'ajouter un myvar2, si toutes les occurances n'ont pas été trouvées, le compilateur les trouvera etc... ) La regle numéro un de la qualité logiciel est ne négliger aucune méthode the qualité. Il est clair que les risques et les types de risque vont privilégier certaines démarches. Ca c'est aussi au chef de projet de définir le steering en fonction de l'environment. Dans les anecdotes: Un module composé de fonctions f, g, h, i etc... appelées en cascade avait besoin de fonctionner avec 4 type de parametres d'appel de f mais la classe était passée aux autres fonctions sans traitement, seule la derniere fonction avait un comportement different en fonction du type. Le mec a copié collé 10 pages de code en faisant de l'édition de texte pour le type car mettre un switch case dans la derniere fonction n'était pas une pratique objet et les deadlines ne permettaient pas d'écrire une base virtuelle. _________________________________ Linux mailing list [email protected] http://lists.parinux.org/mailman/listinfo/linux
