Programmation : les cours d’informatique qui manquent dans le cursus des développeurs

Programmation : les cours d’informatique qui manquent dans le cursus des développeurs
D’après deux blogueurs

Le milieu de l’informatique et celui de la programmation en particulier est en constante progression avec de nouveaux outils, langages ou évolutions et mises à jour de ce qui existe déjà. Si les fondements du métier de programmeur peuvent être acquis à l’école, il existe toutefois de nombreuses astuces et techniques de travail qui s’acquièrent sur le terrain en fonction des outils utilisés, des langages pratiqués et bien d’autres facteurs.

Pour mettre cela en évidence, un blogueur a dressé une liste des cours d’informatique qui n’existent pas mais qui devraient, d’après lui. L’un des cours qu’il propose est une « étude des logiciels classiques ». D’après ce blogueur, ce cours doit permettre aux étudiants de « discuter et disséquer des produits historiquement importants, y compris VisiCalc, AppleWorks, Robot Odyssey, Zork et MacPaint ». L’idée est que comme ces produits ont été développés en tenant compte des limitations matérielles de l’époque, une étude de ces logiciels pourrait permettre aux développeurs d’être plus créatifs et acquérir des techniques pour concevoir des interfaces utilisateurs adaptées à des configurations matérielles limitées.

Un autre cours qui devrait être enseigné d’après le blogueur est l’écriture de codes rapides dans des langages lents. Selon lui, les développeurs devraient par exemple pouvoir « écrire du Python interprété qui peut égaler ou battre le code C ++ typique tout en étant moins fragile et avec lequel il est plus agréable de travailler ».

Il suggère également un autre cours lié à la programmation orientée objet, qui devrait permettre de découvrir comment créer et utiliser des variables qui ne sont pas à l'intérieur d'une hiérarchie d'objets. Le blogueur pense aussi que les développeurs ont besoin d’un cours qui fait une introduction à l’expérience utilisateur pour les outils de ligne de commande. Mais, il propose encore un cours de psychologie sur « les obsessions de l’esprit du développeur ». Le cours devrait permettre d’identifier et de comprendre les sujets qui obsèdent les développeurs de logiciels. Il pense en particulier à « la mise en forme de code, la taxonomie, les systèmes de type, le fractionnement des projets en de nombreux fichiers. » il inclut ici l'étude détaillée du réflexe des développeurs lorsqu'ils sont exposés à des systèmes inconnus.

Inspiré par ce blogueur, un autre développeur a publié un billet sur son blog, dans lequel il propose de compléter cette liste avec trois autres cours. Notre deuxième blogueur pense que la première des choses que les développeurs devraient apprendre, c’est le nommage et l’utilisation des acronymes. Il pense qu’il devrait exister un cours introductif pour « découvrir comment chaque langage fait les choses différemment, et apprendre 1.001 abréviations que vous devez savoir pour comprendre le code des gens. »

La deuxième chose que les développeurs devraient savoir selon ce blogueur est qu’on ne peut rien faire en 5 minutes. L’idée serait d’emmener le développeur à savoir arrêter quand il le faut, et éviter de tomber dans l’illusion selon laquelle, 5 minutes supplémentaires pourraient suffire pour terminer un travail sérieux. De manière plus large, ce cours devrait aborder l’estimation des tâches de développement de logiciels.

La troisième chose sur laquelle il insiste également est que chaque développeur devrait savoir que son code est tout aussi mauvais que ceux des autres. Son objectif est d’éveiller les développeurs sur la nécessité de se respecter les uns les autres et de comprendre la valeur de la collaboration, tout en s’éloignant de l’idée selon laquelle son code est parfait. Il explique par exemple que les développeurs vont découvrir à quel point leur propre code est mauvais s’ils le lisent une semaine après l’avoir écrit.

Sources : Blog Svpino, dadgum.com

Et vous ?

:fleche: Qu’en pensez-vous ?

:fleche: D’après vous, qu’est-ce qui manque dans les cours d’informatique pour les programmeurs ?


:fleche: Forums Programmation

[troll ON]
Donc les trois premiers points sont :
- apprendre à utiliser des vieilles apps Apple,
- apprendre la magie,
- apprendre à faire de la pas-POO en POO.
[troll OFF]

Je me suis arrêté à la liste des applications à étudier... :weird:

Les seuls cours qui m'ont manqué quand je faisais mes études, c'est tout ce qui concerne les tests (travailler avec des testeurs, faire des tests unitaires, avoir les bonnes méthodes pour éviter les régressions... )

Tout ce dont ils parlent ici, ce sont des choses qui s'acquièrent avec la pratique. Même un développeur spécialisé en informatique de gestion n'a pas besoin de cours pour savoir qu'il aura besoin de coder différemment sur un système embarqué.

Les cours qui pourraient manquer m'ont plutôt l'air d'être

1. Utilisation poussée du debugger pour corriger des bugs infâmes
2. Mais à quoi ça sert concrètement ce truc sur lequel on passe un semestre ?
3. Et si on passait plus de temps à faire des exercices à base de TU, TI et TV ?

Le cours qui m'a le plus manqué a été celui sur les modèles de conception (ou "design pattern"). Je ne sais pas si c'est propre à mon école, mais il est aberrant qu'il n'en aie même pas été fait mention!
Je n'aurais pas demandé des dizaines d'heures d'enseignement, mais qqs notions élémentaires pour savoir d'une part qu'ils existent, et d'autre part comment les mettre en oeuvre.
Je les ai découvert qu'après la fin de mes études (la honte)!
Certes, j'en avais déjà utilisé sans en prendre conscience. Mais en avoir connaissance a changé beaucoup de choses; notamment le fait de pouvoir les nommer rend la recherche à leur sujet beaucoup plus facile!

Pour moi, ce qui m'a le plus manqué ce sont des cours plus en adéquation avec le monde de l’industrie.

Par exemple:
- tous mes cours de BDD ont été fait sur MySql (Oracle en SqlServer uniquement mentionné)
- pas un seul cours orienté mobile / web
- par un seul cours sur la façon de faire des tests
- pas un seul cours orienté "produit fini", comment déploie-t-on une application Java ? comment gère-t-on des licences ? comment gère-t-on les mises à jour d'un logiciel ?

Littérature, rédaction, communication, orthographe, comptabilité.....

Ou enseigner aux étudiants à apprendre par eux-même.
Par exemple, à grand coup de « Aux prochain TP, vous aurez besoin de tel outils/bibliothèque, débrouillez vous pour savoir vous en servir »

Pour le reste, il y a énormément de chose qui doivent s'apprendre sur le terrain. C'est pas pour rien que la plupart des formations intègrent un stage en entreprise.

Citation:

---

tous mes cours de BDD ont été fait sur MySql (Oracle en SqlServer uniquement mentionné)

---

Dans mes cours de BDD, on apprenait comment utiliser une base de donnée relationnel. MySQL, Oracle ou autre, le langage reste le SQL. A chaque étudiant de lire les doc des outils spécifiques qu'ils devront utiliser.
Et comme on ne peux pas nous former à tout les outils qui existent, il faut faire un choix. Et faire payer aux étudiant une licence pour qu'ils puissent travailler chez eux, ce n'est pas cool. D'où le choix d'une SGBD libre.

Citation:

---

Envoyé par Roger_Rabbit

Le cours qui m'a le plus manqué a été celui sur les modèles de conception (ou "design pattern"). Je ne sais pas si c'est propre à mon école, mais il est aberrant qu'il n'en aie même pas été fait mention!

---

je pense que c'est un manque de ton école car personnellement, j'en ai bouffé à outrance du design pattern.
Ca a même été une épreuve lors de la licence où on avait du code "écrit sur poly" à analyser et commenter et notamment y déceler les design pattern mis en place ou sinon, lequel il aurait été possible de mettre en place pour le même besoin fonctionnel...


La formation que je trouve qui m'a manqué dans mes études est une formation qualité / intégration continue.
Je trouve qu'il manque un module sur le sujet avec les TU, gestion de branches SVN, pose de tag, tests automatisés, analyseur de code, génération automatique de release note, etc.

Les propositions de ces deux développeurs sont plutôt intéressantes et originales. J'aime bien l'idée que l'on pousse les jeunes à avoir une bonne connaissance de l'histoire de l'informatique et à se pencher sur des problématiques d'une époque où les ressources matérielles étaient nettement plus limitées. :)

Néanmoins, il me semble que ce qui manque actuellement au cursus des développeurs c'est surtout des cours de... développement.
La mode actuelle veut que les écoles tentent à tout prix de former les gestionnaires de demain et de futurs Mark Zuckerberg en herbe. Elles sont tellement obnubilées par l'idée de pousser les jeunes à créer des start-ups et à les former aux affaires qu'entre les cours de business plan et de noeuds de cravate, elles en oublient de les former à l'informatique, c'est à dire à la technique. Même les meilleures écoles d'ingénieur ont l'air de se transformer doucement en école de commerce et/ou gestion bas de gamme. Quand on voit que certaines vont jusqu'à abandonner l'appellation "école d'ingénieur" pour se renommer toute seule en "Business school"* il y a de quoi se poser des questions...



*et pourquoi un anglicisme ridicule ? :/

Je pense que pour pouvoir donner les cours en questions il faudrait déjà des professeurs ayant connu le monde du travail avec une certaine connaissance des problématiques que l'on trouvera en entreprise. :ptdr:

Citation:

---

Envoyé par chiv

Les propositions de ces deux développeurs sont plutôt intéressantes et originales. J'aime bien l'idée que l'on pousse les jeunes à avoir une bonne connaissance de l'histoire de l'informatique et à se pencher sur des problématiques d'une époque où les ressources matérielles étaient nettement plus limitées. :)

---

Cette problématique des ressources limitées est encore très actuelle.
Il y l'informatique embarquée ou encore les smartphone jusqu'à il y a peu
Ce n'est que depuis 4/5 ans qu'on commence à avoir des bêtes de courses qui tiennent dans la poche.
Au temps du premier iPhone (j'ai l'air vieux quand j'écris ça mais ce n'était qu'en 2007), il y avait énormément de contraintes.
Même encore aujourd'hui, sur le mobile, la contrainte du réseau oblige à développer pas mal d'astuce car on ne peut pas compter que la 4G est déployée partout...

Et si on commence à parler des montres connectées, les contraintes matérielles sont énormes, à commencer par la taille de l'écran et que tout est encore à faire côté IHM...

Citation:

---

Néanmoins, il me semble que ce qui manque actuellement au cursus des développeurs c'est surtout des cours de... développement.
La mode actuelle veut que les écoles tentent à tout prix de former les gestionnaires de demain et de futurs Mark Zuckerberg en herbe. Elles sont tellement obnubilées par l'idée de pousser les jeunes à créer des start-ups et à les former aux affaires qu'entre les cours de business plan et de noeuds de cravate, elles en oublient de les former à l'informatique, c'est à dire à la technique. Même les meilleures écoles d'ingénieur ont l'air de se transformer doucement en école de commerce et/ou gestion bas de gamme. Quand on voit que certaines vont jusqu'à abandonner l'appellation "école d'ingénieur" pour se renommer toute seule en "Business school"* il y a de quoi se poser des questions...

---

Complètement d'accord, et c'est un comportement d'ailleurs plutôt franco-français.
Pour l'anecdote, je discutais dernièrement lors d'un covoiturage. La conductrice me demande ce que je fais et j'explique que je suis développeur, en quoi consiste mon travail etc. Rien que du très classique. Tout le monde raconte un peu sa vie pro ou étudiante comme souvent, et vient le tour d'un futur ingénieur en informatique. Alors la conductrice dit quelque chose du genre "Ah bah on a deux développeur alors ?" et il répond sèchement "Ouais au début mais je compte pas faire ça longtemps".
En somme il a l'intention de devenir chef de projet, ou du moins accéder rapidement à un métier de direction ou management.

Ce ne serait pas vraiment un problème si ça n'illustrait pas le comportement d'une bonne partie des têtes bien faites qui sortent des grandes écoles. Et le dénigrement que peut subir le job de développeur (du à mon avis à des rémunérations trop faible comparé à l'investissement nécessaire).
Si on suit ce cheminement, bientôt ou aura des physiciens qui font pas de physique et des docteurs qui ne soignent pas. Tout le monde veut être chef et tout de suite. Et c'est là que s'explique le manque d'innovation dans notre pays, et donc le déficit d'industrie et le problème d'emploi qui en découle.

Bref, il a réussit à me faire sentir un peu naze d'être développeur à 33 ans. Alors que c'est quand même un métier génial, infiniment créatif et cognitif.
Bon, au moins on sera moins ciblé par Alzheimer.

Quand je lis vos réponses respectives, je me rend compte que j'ai du être bien formé, car pour l'instant à part l'intégration continu les cours orienté "produit fini" (à part ceux pour arriver au produit fini...), j'ai eu des cours sur tout ce qui est cité ici...

Pour ma part les cours qui m'auraient été utiles sont:

-les tests unitaires
-les designs patterns
-le versionning (git par ex...)

Par contre ce qui est mentionné dans l'article me semble complètement à l'ouest de mes besoins actuels.

À lire plusieurs des questions sur les forums, je dirais qu'il manque:

Comment utiliser l'aide du programme ?

La TouteTouteToute première chose à apprendre pour faire du développement, c'est d'abords les maths, la logique et l’algorithmie. A voir passer quelques des stagiaires ingénieurs depuis plus de 10 ans, j'ai l'impression que ces notions fondamentales et nécessaires sont, depuis bien longtemps déjà, plus du tout au programme de certaines écoles d'info.

La seconde TouteTouteToute première chose à apprendre est que les 90 premiers % de conception d'un logiciel se font ordinateur éteint, avec un crayon et un papier et en utilisant sa langue maternelle. L'analogie que j'ai indiqué à un membre récemment est celle-ci :

Conçoit la conception de ton logiciel comme si tu allais faire une présentation orale devant une assemblée qui ne connait rien à la programmation*. Bien entendu la présentation se fait en vrai bon français et non pas en C++ ou Java ou autre. Tu commence par les idées générales (sommaire) et ce que doit faire en gros le logiciel (introduction), puis au fur et à mesure de la réflexion(présentation) tu vas du plus général vers le plus détaillé (Chapitres, Paragraphes, etc...). Au final tu abouti à expliquer en détail le moindre petit calcul.

* à un colloque de femmes de ménage comme disait un de mes anciens boss. Et contrairement au coté provocateur de la formule, il fallait y voir aucun irrespect, tout au contraire.

Une fois ce travail fait, le logiciel est quasiment "écrit" en totalité, il ne reste plus qu'à traduire le résultat de cette conception en code, quasiment mot à mot

Un autre point qui devrait être enseigné, et qui ne l'est pas, en France en tout, c'est l'utilisation du débugger, et plus généralement la recherche de bugs, de causes d'erreurs et de plantage dans un code existant. Combien de membres arrivent sur DVP avec un problème de plantage qu'ils n'arrivent pas à résoudre et qu'il ne savent même que leur IDE contient un debugger, qui ne savent même pas ce qu'est une execution pas à pas, une pile d'appel, etc ....

salut à tous

J'aime bien les réponses de jopopmk(apprendre la magie) et el_slapper parce qu'une application n'est pas que du code.

Il y a une chose qui me semble importante, en tant que développeur faisant souvent de la maintenance, c'est de savoir lire du code et de l'interpréter correctement, cela semble simple mais en apparence seulement, ça prend en fait beaucoup de temps. Assez souvent, en ce qui me concerne, la seule doc à jour reste le code. Je sais que cela va être critiqué car ce n'est pas très tendance mais cela a été souvent mon quotidien.

Ceci dit je ne suis pas sûr que cela soit facile à enseigner.

Cdlt

Je passe outre les suggestions ridicules de ce blogueur.

Les cours qui manquent souvent aux développeurs ?
* Les types d'écritures dans le monde (caractères ruby en Asie, ligatures arabes, etc).
* Les encodages de caractères en général et unicode en particulier.
* Tri alphabétique et formatage des nombres et monnaies selon les cultures.
* Les déclinaisons grammaticales dont ont besoin les traducteurs.
* La gestion des entrées pour les langages non-alphabétiques.
* Les problèmes d'accessibilité, notamment pour malvoyants, aveugles et daltoniens.
* Ce qu'il faut savoir sur les noms.
* Ce qu'il faut savoir sur les adresses.
* Ce qu'il faut savoir sur le temps.
* Une formation plus robuste sur la concurrence.
* Une formation plus robuste sur la sécurité.
* Comment lire efficacement un brevet.