Les étudiants sont-ils bien formés à la réalité des métiers du développement logiciel?

Citation:

---

Envoyé par arkhamon

Le recrutement est une chose très complexe et très risquée, qu'il faut faire soit à l'impro, soit avec une batterie de tests de la mort qui tue...
Je ne suis pas sur qu'on puisse repérer un "bon" informaticien avec un ou plusieurs entretiens. Un mauvais programme ne se révèle parfois que plusieurs mois ou années après la mise en prod. C'est en général pile poile après que le "fameux" consultant ait quitté la boite pour une autre mission.

---

On s'est mal compris. Il ne s'agit pas d'évaluer une personne recrutée, mais son degré d'aptitude à appréhender comme il se doit le "métier du développement logiciel" tel que l'entreprise le conçoit.
Rien ne t'empêche de "dégrader la note" d'une école 6 mois après l'arrivée de ta recrue car son travail révèle seulement un manque d'"opérationnalité" à combler

Citation:

---

Envoyé par arkhamon

Embaucher, c'est investir. Pourquoi alors vouloir immédiatement une rentabilité ? L'entreprise ne devrait-elle pas plutôt passer un moment à intégrer l'informaticien dans son schéma global plutôt que de lui demander d'être totalement opérationnel immédiatement ?

---

Tout à fait, je parle de grille de salaires plus justes, si tu sais que tel ou tel établissement va t'amener des développeurs qui n'auront pas les bons réflexes et qui commettront plus d'erreurs avant ton "retour sur investissement" que ceux d'un autre établissement, alors il est logique que le salaire d'embauche soit ajusté en conséquence.
Après si la personne se révèle talentueuse et palier au défaut de sa formation et affiche un réel potentiel (on en revient aux développeurs réellement bons), les augmentations individuelles viendront rectifier le tir

Citation:

---

Envoyé par arkhamon

Programmer c'est quoi ?

• C'est connaître un langage suffisament pour développer, pas nécessairement pour écrire une thèse dessus. Je m'explique : si pour développer des classes de composants pour DElphi, il est préférable de bien maitriser les concepts pointus de POO. Par contre poru uen simple application de gestion est-ce nécessaire ?
• c'est savoir conceptualiser une fonctionnalité afin de la retranscrire en algorithme

Ce sont à mon avis les deux choses qu'on devrait attendre d'un analyste-programmeur.

---

Justement ce n'est pas que ça (savoir faire un code maintenable par exemple est sûrement plus important ce ces 2 critères...à partir d'un code maintenable tu pourras facilement rectifier des lacunes sur ces points, l'inverse est moins vrai), et toute la difficulté c'est de définir la "réalité des métiers de développement"...perso je dirais "les réalités", et là chaque entreprise doit savoir distinguer ses propres besoins pour fixer son barême...malheureusement on tombe trop souvent dans des considérations globales qui ne considèrent pas l'essentiel, et on recrute celui qui a le plus de langages pratiqués sur son CV

Citation:

---

Envoyé par Zweet

Ca ne sert strictement à rien de former une personne sur telle ou telle technologie car les technologies évoluent. Ce qu'il faut en revanche, c'est pouvoir analyser, comprendre le fonctionnement d'une nouvelle technologie, apprendre à se la réapproprier pour ensuite apprendre les mécaniques de la programmation et réutiliser cette technologie.

---

Citation:

---

Envoyé par arkhamon

On souffre en France de ne former que des ingénieurs et des personnes non spécialisés, au détriment de personnes très spécialisées, et donc très performantes. Tout le monde veut être bon partout, c'est un erreur.

---

Former des ingénieurs non spécialisés et vouloir être bon partout sont deux choses différentes. Il est vrai qu'il est généralement de bon ton d'arborer un grand nombre de langages sur son CV, et comme dit plus haut:

Citation:

---

Envoyé par theMonz31

si tu envoies ton CV en disant, je m'en fiche du langage mais prenez moi car je "sais" développer, tu risques d'avoir des refus assez rapides et nets...

---

Le fait est que l'on préférera généralement embaucher quelqu'un qui connaît un minimum la technologie, et qui pourra démarrer rapidement, que quelqu'un qu'on devra former pendant des mois avant de pouvoir lui confier quoi que ce soit...mais c'est une vision bien incomplète au regard de l'investissement. En effet, il est incorrect d'évaluer le coût de l'embauche au coût des 3 premiers mois de formation à une technologie si l'on considère qu'à l'issue de cette formation l'embauché développera, et que ses développements resteront bien plus longtemps que 3 mois: verba volant, scripta manent (c'est un peu pompeux je l'avoue).

Pour un gros projet Java, je préférerais donc 100 fois embaucher un ingénieur formé aux bonnes pratiques du design orienté objet, au TDD, etc. mais qui a surtout fait du C++ et du C# qu'un ingénieur Java qui connait tous les rouages du langage mais qui produit un code que lui seul peut éventuellement faire évoluer.

Il ne s'agit donc pas de former des généralistes qui connaissent un peu de tout, ni des "bons en tout" utopiques, ni des super spécialistes d'une technologie particulière; mais des spécialistes du développement logiciel, des personnes qui savent s'adapter à n'importe quelle technologie et qui développent "bien".

Citation:

---

Envoyé par mattj

Il ne s'agit donc pas de former des généralistes qui connaissent un peu de tout, ni des "bons en tout" utopiques, ni des super spécialistes d'une technologie particulière; mais des spécialistes du développement logiciel, des personnes qui savent s'adapter à n'importe quelle technologie et qui développent "bien".

---

Tout à fait d'accord avec ce point. Un langage ça s'apprend en quelques mois de pratique intensive.
Un esprit de bon développeur par contre c'est plus long et laborieux...

Citation:

---

Envoyé par mattj

Il ne s'agit donc pas de former des généralistes qui connaissent un peu de tout, ni des "bons en tout" utopiques, ni des super spécialistes d'une technologie particulière; mais des spécialistes du développement logiciel, des personnes qui savent s'adapter à n'importe quelle technologie et qui développent "bien".

---

Je ne suis pas tout à fait d'accord ;)

Si je prend ta dernière partie de phrase, avec laquelle je suis 1000% d'accord, "des personnes qui savent s'adapter à n'importe quelle technologie et qui développent "bien"", ce ne sont pas des spécialistes du développement logiciel, ce sont des "têtes bien faites", des gens armés d'esprit critique, de logique, et de culture générale suffisante pour prendre du recul tant par rapport à un problème qu'à une éventuelle solution ou une technologie..

Je pense que l'erreur vient de là, en ayant trop "spécialisé" le développement logiciel, en omettant le fond général, et enfin en omettant (ce qui est lié au terme "développement") que c'est de la création, et donc plus orienté "recherche", que de la reproduction...

Citation:

---

Envoyé par souviron34

Je ne suis pas tout à fait d'accord ;)

Si je prend ta dernière partie de phrase, avec laquelle je suis 1000% d'accord, "des personnes qui savent s'adapter à n'importe quelle technologie et qui développent "bien"", ce ne sont pas des spécialistes du développement logiciel, ce sont des "têtes bien faites", des gens armés d'esprit critique, de logique, et de culture générale suffisante pour prendre du recul tant par rapport à un problème qu'à une éventuelle solution ou une technologie..

---

Oui et non. S'il est vrai qu'un bon dévelopeur doit avoir une tête bien faite, c'est pas pour autant qu'une tête bien faite fera un bon développeur. Je m'explique : des gens peuvent être braillants en électricité, et nuls en mécanique, excellents en plomberie et nuls en électronique... Le développement est un des métiers de l'informatique, et donc en tant que tel est déjà une spécialisation.

Citation:

---

Envoyé par souviron34

Je pense que l'erreur vient de là, en ayant trop "spécialisé" le développement logiciel, en omettant le fond général, et enfin en omettant (ce qui est lié au terme "développement") que c'est de la création, et donc plus orienté "recherche", que de la reproduction...

---

Encore une fois oui et non. Il est vrai que le développement peut être assimilé à de la création. Mais une création terriblement encadrée ! Le développement devrait être fait dans les règles de l'Art. Et comme chacun sait, l'Art possède ses propres canons. Et dans "règles de l'Art", y a "règles"... Et les purs créatifs, justement, ont tendance à se sentir à l'étroit dans des environnements bornés.
D'un autre côté il y a cette théorie du managemetn (moderne) qui dit qu'on n'est jamasi aussi créatif que dasn un environnement borné... Va comprendre... :roll:

Citation:

---

Envoyé par sevyc64

Autre grosse lacune, et très grosse celle-là, c'est que quasiment aucun des jeunes diplômes que j'ai pu côtoyer jusqu'à maintenant ne sais vraiment debugger et tester un logiciel. C'est effarant, d'entendre te dire par de jeunes ingénieurs qui prétendent avoir 5 à 7 ans d'informatique ne pas savoir ce qu'est un point d’arrêt, à quoi ça sert et comment s'en servir.

---

J'étudie en Belgique, cours de soir (promotion sociale), 4ème bachelier en informatique de gestion. En première année c'était Algorithmique et C (en parallèle), l'analyse on l'a vue à partir de la 3ème.

Coder, coder, coder, exécuter, quand ça marche c'est merveilleux. Je sais ce que c'est un point d'arrêt sous Visual et NetBeans et je m'en sers uniquement quand je n'arrive pas à comprendre les messages d'erreur/log , je sais concevoir un test JUnit mais qui a vraiment le temps de concevoir ces tests? Quand c'est un gros projet en équipe ça pourrait aller mais pour une application à rendre (même par groupe de 3 étudiants) dans 2 mois...

La DB de l'application pour mon TFE a 45 tables, je n'ose même pas penser à concevoir le moindre test!:oops:

J'ai internationalisé notre discussion sous la forme d'une question sur programmers SE, à propos des moyens d'améliorer la formation des étudiants:

How to improve the training of students regarding maintainability?

On y trouve quelques réponses intéressantes...

il faudrait que tu édites le lien (sur la page en anglais pointant sur cette discussion-ci), car on tombe sur la 4ième page..


Une des phrases avec lesquelles je suis le plus en accord, et que j'essaye ici-même d'imprimer le plus posible dans les têtes est :

Citation:

---

instill a sense of craftsmanship and quality in the production of software from the outset

---

Cela est cependant délicat, avec le nombre d'étudiants dû aux formations tous azimuths... et les "méthodolgies" usuelles, se basant sur la non-responsabilité et la remplaçabilité...

Tout le monde ne peut pas être artisan...

Mais beaucoup peuvent quand même..

Citation:

---

Envoyé par souviron34

Très bon paragraphe :)

---

Comme dit partiellement dans cette vidéo : http://vimeo.com/14939465. ;)

Citation:

---

Envoyé par mattj

On y trouve quelques réponses intéressantes...

---

mais il en manque une essentielle : KISS

Keep It Stupidly Simple

J'ai déjà cité ailleurs, mais un prof de maths de maths sup il y a bien longtemps nous enseignait, à propos des démonstrations de théorèmes : "ce qui est simple est beau, et a de fortes chances d'être vrai", ce qui e traduit en info par "ce qui est simple est beau, et a de fortes chances d'être facilement maintenable"..

A part pour de l'optimisation poussée, où forcément la lisibilité est moins forte, tout le reste, de l'achitecture globale à l'architecture des répertoires et des fichiers à la programmation aux algorithmes ou aux documents, devrait être guidé par ce principe..

• Savoir du premier coup d'oeil dans quel répertoire on doit aller chercher.
• Savoir du premier coup d'oeil dans quel fichier on doit aller chercher.
• Organiser chaque module/fichier "top-down" avec fonctions internes, internes/externes, et externes.

Si le point 1 est satisfait, alors la compréhension de l'architecture est quasi-imédiate, et on a fait un immense pas en avant vers une maintenabilité accrue.

Si le point 2 est satisfait, alors le "zeroing" sur le(s) fichier(s) à modifier/regarder est quasi-immédiat.


Par exemple : (à mon avis)

• identifier l'IHM comme quelque chose d'à part , possiblement remplaçable sans changer le reste : par exemple un répertoire IHM, avec un sous-répertoire Java (qui pourra être additioné si on le souhaite d'un répertoire Motif ou Web ou commandlanguage)
  
• identifier l'accès BD comme quelque chose d'à part, possiblement remplaçable sans changer le reste : par exemple un répertoire BD, avec un sous-répertoire SQL, (qui pourra être additioné ou non, si on le souhaite, de ACCESS, de FLAT, .de ObjectDB..)

Ces pratiques imposent la formalisation d'une "couche" ou plutôt d'une API pour chaque très gros élément, obligeant à un effort de conception mais débouchant sur une maintenabilité accrue, que ce soit au niveau des découpages ou des architectures.


Maintenant, par rapport aux discussions pointées, je pense que pour l'enseignement effectivement soit des exemples croisés (codes par 1/2 de la classe, ajout par l'autre), ou même en binômes, serait déjà un plus..

Tu peux aussi penser à faire un code assez complexe (ça dépend du niveau des étudiants), et le coder d'une façon propre et d'une façon assez dégeu.. Mais le mieux serait que chacun le code, avec une spec assez précise, mais sans que tu le juge. Et, une fois ceci fait, tu ajoutes 1 ou 2 fonctionalités un peu complexes (par exemple soit transverse, soit avec un nouveau type de donnée, soit ...)...

Les 2 sont complémentaires.. Et donc les 2 seraient à faire ;)

Je viens de penser à un truc horrible : on donne un projet à chaque étudiant, puis on lui donne une maintenance sur le code d'un autre étudiant. Et on continue à tourner.....:aie:

A voir, il y a sans doute 1000 raisons de ne pas le faire. Mais ce genr d'idée cruelle me plait beaucoup.

Citation:

---

Envoyé par el_slapper

Je viens de penser à un truc horrible : on donne un projet à chaque étudiant, puis on lui donne une maintenance sur le code d'un autre étudiant. Et on continue à tourner.....:aie:

A voir, il y a sans doute 1000 raisons de ne pas le faire. Mais ce genr d'idée cruelle me plait beaucoup.

---

Petite précision, on donne en maintenance le code d'un étudiant de l'année précédente, bien entendu, sur un projet ou l'étudiant ne connais rien, si ce n'est ce que est censé faire le programme, et le problème qu'il a.

Pour une idée cruelle, c'est une réalité que bon nombre de développeurs professionnels se farcissent au quotidien, 8h/jour.

Citation:

---

Envoyé par el_slapper

Je viens de penser à un truc horrible : on donne un projet à chaque étudiant, puis on lui donne une maintenance sur le code d'un autre étudiant. Et on continue à tourner.....:aie:

A voir, il y a sans doute 1000 raisons de ne pas le faire. Mais ce genr d'idée cruelle me plait beaucoup.

---

Délicieuse idée ! :wow:
La pédagogie par la découverte...

Au fait, j'adore ta signature...

Citation:

---

Envoyé par el_slapper

Je viens de penser à un truc horrible : on donne un projet à chaque étudiant, puis on lui donne une maintenance sur le code d'un autre étudiant. Et on continue à tourner.....:aie:

A voir, il y a sans doute 1000 raisons de ne pas le faire. Mais ce genr d'idée cruelle me plait beaucoup.

---

J'aime beaucoup cette idée, seulement, les projets sont tellement faits à l'arrache la plupart du temps que je n'oserais pas mettre mon nez là dedans :mrgreen:

Citation:

---

Envoyé par Zweet

J'aime beaucoup cette idée, seulement, les projets sont tellement faits à l'arrache la plupart du temps que je n'oserais pas mettre mon nez là dedans :mrgreen:

---

Comme dit par d'autres : c'est mon quotidien. Sauf que les gens qui ont écrit les programmes que je maintiens étaient jeunes au moment de l'écriture et sont à la retraite maintenant. Certains étaient civilisés. D'autres non.

Mais le pire, je crois, ce sont les générateurs de code. Un jour ou l'autre, le générateur est perdu, et on se retrouve avec un généré qui a des noms de variables, beeeen, générés. Donc imbitables. Plus une indentation farceuse, une organisation du code aléatoire, et des paragraphes indiscernables. Heureusement, tous ne se basent pas sur de l'ALTER PROCEED(pour ceux qui ne connaissent pas cobol, ça altère la destination d'un GO TO. C'est interdit partout, d'ailleurs le GO TO lui même est interdit presque partout, mais j'en connais qui en on subi :aie: ).

Je reformule mon idée, alors : on prend le meilleur et le pire de l'année précédente. On donne alors le pire à maintenir. Et, quand les étudiants ont passé une semaine à gémir, on leur ressort le meilleur. "C'est plus facile, non? N'oubliez jamais que le mainteneur le plus fréqent d'un code, c'est son auteur, et qu'au bout de 6 mois, il a tout oublié".....

Pour ce qui est de ma signature, j'avais trouvé Michael C. Kasten en essayant de trouvé des pistes sur comment faire de l'objet en cobol(je sais, je suis un pervers). Je n'ai jamais réussi à compiler, il disait juste que c'était particulièrement compliqué, sans dire comment il avait fait. Mais il y avait sur son site quelques formulations amusantes, et celle-ci m'a paru particulièrement pertinente. (la partie non-allégiance étant moins drôle, je suppose que arkhamon faisait allusion à la première partie de ma sig). Il rajoutait "pour tout projet non-trivial", mais j'arrivais aux limites de caractères de la sig.

Citation:

---

Envoyé par el_slapper

comment faire de l'objet en cobol(je sais, je suis un pervers).

---

Je pense que là on dépasse la perversité, on atteint l'ultime... :mouarf:
Et pour la signature, si la première partie me semble triviale, la seconde a une portée plus "philosophique" et du coup a plus de valeur à mes yeux...
Donc j'aime les deux parties, et la seconde devrait être un peu plus souvent assénée (excusez pour le mot mais bon...) à toute une palenquée de managers obnubilés par le budget, le calendrier et les meeteings de suivi...

Personnellement, je suis dans le cas ou effectivement la majorité de mon job consiste à maintenir un ERP développé par une entreprise tierce. La maintenance ne me pose pas de problème quant à une "dévaluation" (mot peut-être trop fort ou inadapté, mais je n'en ai pas d'autre) du métier de développeur. Ce qui m'effare c'est le manque d'implication de jeunes développeurs dans la réalisation d'un projet. Si j'avais le temps, je pourrais écrire un bouquin sur les "do and don't" dans l'ecriture d'un logiciel relativement conséquent. Mais ce qui me tue le plus, c'est de voir des erreurs grosses comme des maisons visibles à la lecture du code, jamais testées (sinon l'erreur serait corrigée tant elle était inevitable) mais tout de même livrées au client avec l'assurance que tout est OK.

Pour conclure, j'aimerais faire part d'un principe qui me semble pouvoir apporter de la maturité aux jeunes développeurs: "Tester une fonctionnalité ce n'est pas essayer de la faire fonctionner, mais bien essayer de la planter. Si on n'y arrive pas, c'est qu'elle est bien écrite". Si, en codant et en testant, on applique ce principe, on va, premièrement, amener mons de bugs dans l'application et deuxièmement acquérir une mécanique de codage-test plus efficace pour les développements futurs.

En espérant que vous trouverez mon intervention pertinente

Citation:

---

Envoyé par el_slapper

Mais le pire, je crois, ce sont les générateurs de code.

---

oui.. J'ai quelques souvenirs d'horreurs absolues.. En particulier les générateurs de code d'IHM... : chaque bouton a par exemple sa callback, qui porte un nom du style Frame1.button1.onClick ... Super pour s'y retrouver :aie:

J'ai eu aussi : des appels de fonction sont inclus dans des "include" en factorisant des paramètres....

Du style :

Code:

---

1 2 3 4 5 6 7

toto ( int a, int b, double c ) { ... } .... toto1(1,2);

---

Dans le code, et

Code:

---

#define toto1(a,b) toto(ab,-2.0)

---

dans un .h (bien entendu inclus dans un .h lui-même inclus dans un autre).

Je vous raconte pas la galère.. Surtout qund cette pratique a été généralisée pour un code de 300 000 lignes... Bien entendu, dans ce cas, tout debugger est inutile : il n'indique jamais l'association, et quand on débugge en pas à pas, on se demande bien pourquoi on passe d'un appel de toto1 dans la fonction toto :aie:

Citation:

---

Envoyé par goudax

"Tester une fonctionnalité ce n'est pas essayer de la faire fonctionner, mais bien essayer de la planter. Si on n'y arrive pas, c'est qu'elle est bien écrite".
...
En espérant que vous trouverez mon intervention pertinente

---

:ccool:

Tout à fait, nonn seulement pertinente, mais parfaitement exacte :)

Mais c'est à mon avis aussi un reproche qu'on peut faire aux méthodologies en général et au concept de TU et de leur documentation...

Les TU ne font que tester le fait de faire fonctionner la fonctionalité...

Citation:

---

Envoyé par goudax

Pour conclure, j'aimerais faire part d'un principe qui me semble pouvoir apporter de la maturité aux jeunes développeurs: "Tester une fonctionnalité ce n'est pas essayer de la faire fonctionner, mais bien essayer de la planter. Si on n'y arrive pas, c'est qu'elle est bien écrite". Si, en codant et en testant, on applique ce principe, on va, premièrement, amener mons de bugs dans l'application et deuxièmement acquérir une mécanique de codage-test plus efficace pour les développements futurs.

---

En maths, on appelle ça demonstration par l'absurde : si on ne peut pas prouver qu'une chose est vraie, on prouve qu'elle ne peut pas être fausse (en laissant de côté la logique floue ou ternaire...). On parle aussi de stress-test : en poussant une fonction jusque dans ses derniers retranchements, on constate si elle tient la route ou pas.

D'ailleurs, en parlant de ça, j'ai vu je sais plus trop où qu'un langage introduisait une "troisième" état dans le booléen : incertain ou un truc de ce genre. J'avais fumé ou d'autres ont vu ça aussi ? Je me demande si c'était pas dans la prochaine version de Java...

Citation:

---

Envoyé par goudax

En espérant que vous trouverez mon intervention pertinente

---

Ouais j'ai même "plussé" (Dieu que j'aime pas ce mot là)...

Citation:

---

Envoyé par souviron34

oui.. J'ai quelques souvenirs d'horreurs absolues.. En particulier les générateurs de code d'IHM... : chaque bouton a par exemple sa callback, qui porte un nom du style Frame1.button1.onClick ... Super pour s'y retrouver :aie:

---

J'ai le souvenir d'avoir écrit il y a très longtemps un générateur de code en Turbo Pascal pour du code en Turbo Pascal.
Ca marchait. Mais il faut bien admettre certains points quant à l'utilisation d'un générateur de code :

• Tant qu'on reste dans le "classique", le code généré est correct, avec cette petite restriction sur le nom des variables : on peut rarement faire preuve de créativité comme le fait un développeur
• Dès qu'on s'aventure dans des contrées inexplorées, ben justement ça devient l'aventure...
• quand on veut descendre dans du code pondu par un générateur de code, on a tout intérêt à s'adresser au concepteur du générateur, on gagnera beaucoup de temps et on risquera moins de migraines...

Je n'ai jamais pondu de générateur de code en environnement Windows, je n'en ai jamais eu le besoin. Mais je serais tenté de dire comme ça à première vue, que forcément le code généré risque d'être encore moins lisible. Sans aller jusqu'au "#define toto1(a,b) toto(ab,-2.0)" dans des .h (t'as qu'à pas faire de C t'auras pas de .H :aie::aie::aie: pas taper), je pense effectivement que le code généré par un générateur étant censé être exempt de tout bug (ça serait la moindre des choses...), on n'est pas trop censé descendre dedans. Et s'il faut que l'utilisateur du générateur se tape les noms de variables, ca rend pas l'opération moins intéressante ?

Dernier petit point : j'ai le souvenir d'utiliser les générateurs de code pour pondre des IHM. Mais maintenant qu'on a des outils de développement graphiques (sauf Eclipse :aie::aie::aie: pas taper), je me demande quelle peut être l'utilité d'un générateur d'IHM... Techniquement je vois l'avantage (l'informaticien est fainéant, il préfère bosser 10 jours sur un générateur de code plutôt que de retaper le même code pendant une journée), mais économiquement je vois moins... Peut être le fait de n'avoir qu'un seul code à débugger... ?