IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Etudes Discussion :

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


Sujet :

Etudes

  1. #1
    Membre habitué

    Homme Profil pro
    Inscrit en
    Septembre 2005
    Messages
    36
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations forums :
    Inscription : Septembre 2005
    Messages : 36
    Points : 129
    Points
    129
    Par défaut Les étudiants sont-ils bien formés à la réalité des métiers du développement logiciel?
    Il s'agit en fait d'un débât en deux parties.

    La première peut se résumer à cette question sur programmers.stackexchange.com. Le développeur qui pose la question semble surpris de constater que l'essentiel de son métier n'est pas le développement de nouveaux logiciels mais plutôt la maintenance de logiciels existants. Il évalue même le rapport entre les deux à 90%/10%.
    La première question est donc : pensez-vous que l'essentiel du métier de développeur consiste à maintenir des logiciels existants ?
    Personnellement je pense que, sans atteindre une proportion de 90/10, la maintenance constitue l'essentiel du métier: on doit modifier des logiciels existants et concevoir de nouveaux logiciels en pensant à leur maintenabilité.

    La deuxième - la question principale - est donc la suivante : Pensez-vous que les universités, les écoles françaises, préparent correctement les étudiants aux métiers du développement logiciel ? J'inclus dans cette question à la fois le métier de développeur (analyste/développeur...) et celui d'ingénieur d'étude et de développement, dont les responsabilités en matière d'architecture logicielle sont supérieures.

    Je ne dirais pas où j'ai fait mes études car je sais que les programmes ont pas mal changé là-bas depuis et je ne veux pas faire de mauvaise pub, mais pour ma part je n'ai pas été formé correctement à la réalisation de logiciels dans un milieu professionnel. En particulier je n'ai reçu aucune formation en ce qui concerne la maintenabilité. Jamais je n'ai appris à concevoir une application avec pour objectif de la rendre maintenable dans le cadre de mes études. Je trouve cela d'autant plus surprenant que la littérature sur le sujet existe depuis les années 90', je pense notamment à Robert C. Martin. En fait, pour caricaturer, j'ai plus l'impression que l'on forme plus les étudiants à créer des applications "de loisir" que des applications professionnelles.

    Une petite idée pour conclure: en stage on demande généralement aux étudiants de réaliser un projet complet. Pendant leurs études ils doivent réaliser un grand nombre de projets du début à la fin. Devrait-on avoir un cours de maintenance où l'on donnerait comme projet annuel un sujet du genre "Rajouter telle ou telle fonctionnalité" à un projet mal "designé" ?
    Matthias
    Chef de projet et développeur
    http://matthiasjouan.fr/

  2. #2
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Janvier 2007
    Messages
    10 191
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 191
    Points : 28 070
    Points
    28 070
    Par défaut
    Pour la première partie, tout dépend du poste occupé. Pour ceux qui travaillent essentiellement au projet ponctuel (même s'il est long), ils ne feront probablement que peu de maintenance.
    Ceux, par contre travaillant sur de la plus longue durée, faisant carrière dans une même entreprise par exemple, ou autre, feront effectivement beaucoup de maintenance de l'existant. Si le rapport 90/10 semble correspondre au cas particulier de l'auteur cité, à bien analyser les choses, la part de maintenance est très probablement majoritaire, oui!

    Pour la seconde partie, je n'ai pas fait d'école d'informatique donc je ne sais pas précisément ce qui s'y enseigne, mais j'en ai malgré tout une bonne vision par l'intermédiaire notamment des jeunes diplômés que j'ai eu l'occasion de côtoyer.
    Il me semble qu'il leur ait plus enseigner tout ce qui est analyse, conception, gestion de projet, etc.
    Par contre, ils ont généralement de grosses lacunes dans tout ce qui est codage, que ce soit les bonnes règles, l'organisation du code, la maintenabilité donc, mais aussi la traduction des études de conception en code qui fonctionne.
    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.
    --- Sevyc64 ---

    Parce que le partage est notre force, la connaissance sera notre victoire

  3. #3
    Membre habitué

    Homme Profil pro
    Inscrit en
    Septembre 2005
    Messages
    36
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations forums :
    Inscription : Septembre 2005
    Messages : 36
    Points : 129
    Points
    129
    Par défaut
    Citation Envoyé par sevyc64 Voir le message
    il leur ait plus enseigner tout ce qui est analyse, conception
    Un problème que j'ai coutume de relever lorsque je discute du sujet : que ce soit sur le Web, dans les livres ou en cours, les notions telles que les design patterns sont presque toujours enseignés à l'envers.
    Un cours de conception objet pourrait par exemple débuter par : "Le cours d'aujourd'hui sera consacré au pattern Stratégie. Le pattern Stratégie consiste..." En revanche le cours ne commencera pratiquement jamais par "Reprenons l'exemple de la semaine dernière: nous voulons ajouter un nouveau moyen de faire blabla, qui pourrait être utilisé par la classe X à la place de la classe Y. Pour l'instant la classe X instancie un Y dans son constructeur..."

    En tout cas peut-être un élément de réponse à:
    Citation Envoyé par sevyc64 Voir le message
    ils ont généralement de grosses lacunes dans tout ce qui est codage, que ce soit les bonnes règles, l'organisation du code, la maintenabilité donc, mais aussi la traduction des études de conception en code qui fonctionne.
    avec lequel je suis entièrement d'accord.
    Matthias
    Chef de projet et développeur
    http://matthiasjouan.fr/

  4. #4
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Les rapports classiques sont entre 70/30 et 80/20 pour de la maintenance. Un lien présent sur la discussion de stack est à 64/36.

    Après, la distinction n'est pas toujours évidente. En 2008, j'ai été amené à refondre un existant de 1972(une génération d'impressions à destination des clients). Dans le même langage. Par bien des aspects, c'était du projet : nouveau code, nouveau formats de fichiers, nouvelle sortie pour l'impression..... mais aussi de la maintenance préventive : en remettant le code dans un ordre logique(après 36 ans de maintenance, ça bavait de partout, et les mêmes données étaient modifiées bien des fois tout au long du traitement), en corrigeant au passage certains bugs que personne n'avait jamais detecté, en refactorisant les algorithmes, et tout simplement en s'insérant "en douceur" dans les chaines existantes, au même endroit que les anciennes.

    Suivant comment on compte, on arrivera à 60% ou 90%. Mais on travaille majoritairement sur ce qui marche.


    Pour ce qui est de la formation, c'est pareil partout. J'ai fait une formation d'ingénieur plasturgiste, et nous étions bien mieux préparés à la R&D qu'à la production, qui constituait une part non négligeable des emplois. Mais peut-être était-ce quand même mieux identifié qu'en informatique. Nous savions qu'il fallait des ingénieurs de production, bien avant d'être diplômés.

    Pour ce qui est des capacités des codeurs frais sortis des écoles, j'en sais rien. Je fais surtout du cobol, et on a assez peu de jeunots.....
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  5. #5
    Membre habitué

    Homme Profil pro
    Inscrit en
    Septembre 2005
    Messages
    36
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations forums :
    Inscription : Septembre 2005
    Messages : 36
    Points : 129
    Points
    129
    Par défaut
    Je n'avais pas pensé à cet aspect lorsque je rédigeais mon message initial, mais peut-être que cobol est l'exemple absolu.
    Cobol représente, si l'on en croit MicroFocus, une part importante des applications actuellement utilisées dans les entreprises, et donc une part importante de l'activité maintenance/évolution. Pourtant je ne pense pas que beaucoup de formations l'incluent dans leurs programmes:
    Je fais surtout du cobol, et on a assez peu de jeunots...
    Personnellement je n'ai jamais vu de carte perforée pour de vrai
    Matthias
    Chef de projet et développeur
    http://matthiasjouan.fr/

  6. #6
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par mattj Voir le message
    Je n'avais pas pensé à cet aspect lorsque je rédigeais mon message initial, mais peut-être que cobol est l'exemple absolu.
    Cobol représente, si l'on en croit MicroFocus, une part importante des applications actuellement utilisées dans les entreprises, et donc une part importante de l'activité maintenance/évolution. Pourtant je ne pense pas que beaucoup de formations l'incluent dans leurs programmes:
    En même temps, MicroFocus a tendance à en rajouter(pour des raisons marketing évidentes). Cobol, c'est une niche, y'en a, et y'a des gens qui savent faire. Pas besoin de milliards de jeunots, parfois y'en a un qui se forme sur le tas, et ça suffit(à mon grand regret, j'aimerais être une ressource rare, donc chère).

    Citation Envoyé par mattj Voir le message
    Personnellement je n'ai jamais vu de carte perforée pour de vrai
    Moi non plus. Mon père non plus(et il a commençé en 72).
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  7. #7
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 603
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par mattj Voir le message
    Pensez-vous que l'essentiel du métier de développeur consiste à maintenir des logiciels existants?
    Citation Envoyé par sevyc64 Voir le message
    Pour la première partie, tout dépend du poste occupé. Pour ceux qui travaillent essentiellement au projet ponctuel (même s'il est long), ils ne feront probablement que peu de maintenance.
    Ceux, par contre travaillant sur de la plus longue durée, faisant carrière dans une même entreprise par exemple, ou autre, feront effectivement beaucoup de maintenance de l'existant. Si le rapport 90/10 semble correspondre au cas particulier de l'auteur cité, à bien analyser les choses, la part de maintenance est très probablement majoritaire, oui!
    @sevyc64 : Je ne suis pas d'accord avec ta "séparation", très française.. Ce n'est pas parce qu'on reste longtemps dans la même boîte que l'on fait plus de maintenance..

    Cela dépend du domaine, principalement.. et du profil de qui on parle...

    Il est relativement évident que dans la fabrication de sites Web et d'applis mobiles ou web, on fait plus de dev que de maintenance...

    Par contre (et là à mon avis il y a effectivement une énorme lacune de connaissances, de prise de conscience et de formation, que ce soit pour les jeunes diplômés ou les profs) dans une grande majorité de domaines industriels la maintenance est le coeur, pour la simple raison de la durée de vie et du coût de développement de la plupart des logiciels..

    Outre les héritages (de Fortran , Cobol, C, Prolog, Pascal, Delphi, VB, Motif, ou Forms et autres GKS) de "vieux" outils fonctionnant parfaitement, et représentant non seulement une masse de code considérable mais également une connaissance et un débuggage souvent à toute épreuve (à l'époque c'était souvent des gens du métier qui développaient, et il y a souvent plus de 30 ans de débuggage), même les nouveaux doivent répondre à des impératifs de durée de vie longue... Et souvent même les sites / applis Web...

    De ce que je vois des formations et des devs présentés ici (sans même compter les sites où on clique et où on voit que ce n'est pas mis à jour depuis 5 ans...), il y a effectivement une lacune profonde en ce qui concerne la maintenabilité et le fait de prendre en compte le futur, et je ne parle pas du futur à 2 ans....

    Mais tout ceci, et je l'ai déjà dit ailleurs, provient à mon avis essentiellement et de l'engouement des jeunes vers l'info dû aux jeux et au contact très tôt avec la progammation, et à l'engouement (indû) des moins jeunes pour l'info et de la culture de l'enfant-roi où tous ces jeunes sont des "petits génies" en puissance, et la "créativité" est la source de tout...

    Moi qui suis maintenant un "vieux", je savais dès 1982 que les formations en info étaient juste le remplacement des formations de "secrétaires", et q'on allait former des générations d'"ouvriers" , pas manuels mais intellectuels..

    Tout ce que vous notez provient de celà : à la base 3 illusions :

    • une illusion d'abord que "tout ce qui et nouveau est bien et tout ce qui est ancien est obsolète"
    • une illusion ensuite que "n'importe qui avec de la créativité peut devenir Steve Jobs ou Bill Gates"
    • et enfin une illusion que "n'importe qui avec de la créativité pourra trouver un boulot lui correspondant".


    ça se saurait si tout le monde pouvait être architecte ou compositeur... ou même si n'importe quel musicien pouvait être compositeur... ça se saurait si n'importe quel physicien pouvait avoir un Prix Nobel ou avoir une équation à son nom... ça se saurait si n'importe quel mathématicien pouvait laisser un théorème... Pourquoi l'informatique serait-elle différente ???

    Ce qui a été mal transmis et mal assimilé est que, dans l'info comme en musique, la majorité des "instrumentistes" jouent les oeuvres de quelques autres...

    La prise en compte de ça débouche immédiatement sur la notion de maintenabilité....

    De plus, l'engouement et l'enseignement de langages plus ou moins ésotériques ou de "dernière" génération propae cette idée qu'il n'y a pas à penser au passé (et donc au futur)... (voir plus bas...)



    Citation Envoyé par mattj Voir le message
    Pensez-vous que les universités, les écoles françaises, préparent correctement les étudiants aux métiers du développement logiciel?
    Citation Envoyé par sevyc64 Voir le message
    Par contre, ils ont généralement de grosses lacunes dans tout ce qui est codage, que ce soit les bonnes règles, l'organisation du code, la maintenabilité donc, mais aussi la traduction des études de conception en code qui fonctionne.
    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.
    Je ne travaille que peu avec des jeunes, mais il suffit de voir ici, que ce soit sur les forums techniques ou sur ce forum, à propos des debuggers et autres, ou de la lisibilité du code..

    Quant à la conception, il suffit de regarder un peu le forum Conception ou Architecture pour s'apercevoir que le bon sens et la logique sont (souvent) écrasés par l'application de modèles / patterns pré-définis...

    Quant à la doc, n'en parlons pas... Entre le "tout javadoc" et le "rien"...


    Citation Envoyé par mattj Voir le message
    Personnellement je n'ai jamais vu de carte perforée pour de vrai
    Moi si Le sujet de thèse d'une de mes collègues à l'époque était la traduction d'un programme scientifique de cartes perforées en programme "fichier".. Et c'était en 1982 ...
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  8. #8
    Membre expert Avatar de air-dex
    Homme Profil pro
    Inscrit en
    Août 2010
    Messages
    1 653
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France

    Informations forums :
    Inscription : Août 2010
    Messages : 1 653
    Points : 3 773
    Points
    3 773
    Par défaut
    Citation Envoyé par sevyc64 Voir le message
    Pour la seconde partie, je n'ai pas fait d'école d'informatique donc je ne sais pas précisément ce qui s'y enseigne, mais j'en ai malgré tout une bonne vision par l'intermédiaire notamment des jeunes diplômés que j'ai eu l'occasion de côtoyer.
    Il me semble qu'il leur ait plus enseigner tout ce qui est analyse, conception, gestion de projet, etc.
    Les écoles d'informatique comportent il est vrai pas mal d'enseignements pour le jour où la technique et le codage sont abandonnés (management, gestion de projets, etc.). J'y étais encore il n'y a pas si longtemps.

    Citation Envoyé par sevyc64 Voir le message
    Par contre, ils ont généralement de grosses lacunes dans tout ce qui est codage, que ce soit les bonnes règles, l'organisation du code, la maintenabilité donc, mais aussi la traduction des études de conception en code qui fonctionne.
    Ca s'apprend en école mais après je pense que la mise en place des bonnes pratiques dépend des personnes. C'est là que ce fait la différence entre les développeurs qui font les choses et celles qui les font bien.

    Citation Envoyé par sevyc64 Voir le message
    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.
    Un gros, que dis-je un énorme +1. Mon apprentissage des débuggeurs se limite officiellement au verso d'une feuille de TP expliquant comment fonctionne GDB dans les grandes lignes (et GDB était loin d'être le point central de ce TP). Pour le reste, c'est un cour de bonnes pratiques si tu choisis la filière orientée développement. Autant dire que c'est succint.
    "Ils ne savaient pas que c'était impossible alors ils l'ont fait." Mark Twain

    Mon client Twitter Qt cross-platform Windows et Linux. (en cours de développement).

  9. #9
    Membre actif Avatar de IsiTech
    Homme Profil pro
    Développeur mobile
    Inscrit en
    Janvier 2012
    Messages
    105
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur mobile

    Informations forums :
    Inscription : Janvier 2012
    Messages : 105
    Points : 268
    Points
    268
    Par défaut
    Je viens de valider ma L3 Informatique et je continue en master, donc point de vue étudiant.

    On a très peu de cours de conception (Et encore, on a à peine vu le pattern MVC), aucun de gestion de projet, et pas énormément de programmation. Au delà des cours, on a aucune information sur les métiers ou retours de professionnels. Pas de stage non plus hormis stage de fin d'étude. Donc en effet je ne pense pas être bien préparé et informé aux métiers du développement logiciel qui est pourtant ceux qui m'intéressent.

    Concernant le code, on a différents projets à réaliser mais on a aucun retour, on nous communique juste notre note (Et encore...). Avoir un avis sur le projet est déjà compliqué, alors avoir un avis sur le code est impossible. C'est vraiment dommage car on a besoin d'aide extérieure pour améliorer son code.

    Au final je trouve le programme de mon université peu adaptée, c'est d'autant plus bête que c'est une fac bien cotée. C'est vraiment dommage.

  10. #10
    Membre régulier
    Profil pro
    Inscrit en
    Février 2008
    Messages
    41
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2008
    Messages : 41
    Points : 81
    Points
    81
    Par défaut
    Pendant mes études il y a quelque chose qui m'a vraiment choqué, en BTS tous nos profs avait une expérience professionnelle en informatique, donc ont étaient vraiment sensibilisés à ces problématiques, pour la maintenance on a même eu un projet "fil rouge" qui à duré sur 2 ou 3 mois.
    Mais après je suis arrivé en L3, et là j'ai vu que la plupart des profs n'avais jamais travaillé de leur vie, ne faisaient que du travail théorique ou des prototypes, et surtout : n'apprenait pas à développer (ne savant pas réellement le faire eux-mêmes). Ça m'a complètement dégouté des cours, le fait que l'on sait que l'on apprend pas grand-chose d'utile et surtout "choqué" de voir des futurs ingénieurs avoir un niveau aussi bas (c'est pas de leur faute, c'est juste les universités qui recrutent n'importe qui comme prof sans regarder les CV), et j'espère vraiment que toutes les universités ne sont pas comme celle où j'ai été.

  11. #11
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Lead dév - Architecte
    Inscrit en
    Août 2003
    Messages
    6 690
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Lead dév - Architecte
    Secteur : Industrie

    Informations forums :
    Inscription : Août 2003
    Messages : 6 690
    Points : 20 211
    Points
    20 211
    Par défaut
    Les études d'informatique que j'ai pu faire on pour la plus part du temps été mal adaptée au monde professionnel.

    j'avais par exemple énormément de conception. UML , merise , et on ne pouvait pas faire une ligne de code sans une étude complète. Certes très formateur mais je n'ai depuis jamais eu le temps de le faire réellement (un petit diagramme sur un coin de post it dans le meilleure des cas).
    Parce que entre avoir une conception au poil ou avoir une jolie interface rapidement , le client à vite fait son choix.

    En ce qui concerne la maintenance , c'est un peu le cycle infernal. Etudiants pas formés , donc projet galère à maintenir , ces étudiants non formé ne feront sans doute jamais l'effort de coder en vue de la maintenance et donc ne transmettrons jamais cette expérience à d'éventuels stagiaires.

    Après il y'a aussi la réalité du terrain. Les timelines et les directions non technique te force parfois (hélas) à faire un boulot dégueulasse ...
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  12. #12
    Membre éclairé
    Homme Profil pro
    Inscrit en
    Juin 2010
    Messages
    319
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France

    Informations forums :
    Inscription : Juin 2010
    Messages : 319
    Points : 843
    Points
    843
    Par défaut
    ... En stage on demande généralement aux étudiants de réaliser un projet complet. Pendant leurs études ils doivent réaliser un grand nombre de projets du début à la fin. Devrait-on avoir un cours de maintenance où l'on donnerait comme projet annuel un sujet du genre "Rajouter telle ou telle fonctionnalité" à un projet mal "designé" ?
    Je suis totalement d'accord avec ta proposition !
    Un de mes projets de seconde année d'école d'ingénieur a été de réaliser en trois mois un mini DPI (Dossier Patient Informatisé, utilisé dans les hôpitaux).

    S'il est vrai que les trois profs suivant les projets pouvaient difficilement passer en revu tout le code de la demi-douzaine de groupes, la note finale reposaient principalement sur "la gestion du projet" ; çàd avoir rempli ce qu'on avait mis dans le cahier des charges initial.

    L'argument principal étant : "Les trois-quarts d'entre vous passeront chefs de projet dans 3-4 ans" ... et en attendant on fait quoi ?! Et si on veut rester en R&D ?!

    Et j'ai l'impression que c'est pareil pour beaucoup d'écoles d'ingénieurs qui proposent une formation dans le domaine informatique.
    Certes, savoir discerner le besoin du désir du client, concevoir un cahier des charges fonctionnelles et techniques, ça aide à ne pas coder quelque chose qui ne sera jamais utilisé. Mais si la fonctionnalité requiert 10 requêtes en base alors qu'une seule pourrait suffire, il vaut presque mieux que la fonctionnalité n'eut pas existé ...

    Donc en attendant, j'ai appris seul, et ce n'est pas toujours le meilleur moyen de procéder.
    "Donnez un poisson à un Homme, et il mangera un jour. Apprenez-lui à pêcher, et il mangera tous les jours."

  13. #13
    Membre confirmé
    Inscrit en
    Octobre 2007
    Messages
    210
    Détails du profil
    Informations forums :
    Inscription : Octobre 2007
    Messages : 210
    Points : 459
    Points
    459
    Par défaut
    Ce qu'il manque dans l'enseignement à l'université, ce sont toutes les méthodes de développement de qualité. Test unitaires, Refactoring, nommage correct des classes/méthodes/variables, indentation correct du code (oh purée ça... ne jamais prendre un stagiaire sans CheckStyle!), DRY, principes et mise en place d'une intégration continue, procédures/scripts de déploiement automatisés (devops), gestion des versions logicielles ...


    Pour se dégager de ses responsabilités, l'enseignement évoque la sacro-sainte séparation entre enseignement et monde du travail : "On vous enseigne les bases, le reste vous l'apprendrez en entreprise !".
    Ou encore "On vous enseigne les additions, et pour les multiplications vous les verrez en entreprise".

  14. #14
    Expert confirmé
    Avatar de GLDavid
    Homme Profil pro
    Service Delivery Manager
    Inscrit en
    Janvier 2003
    Messages
    2 851
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Service Delivery Manager
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : Janvier 2003
    Messages : 2 851
    Points : 4 743
    Points
    4 743
    Par défaut
    Bonjour

    Un petit avis qui vaut ce qu'il vaut mais qui confortera les opinions déjà décrites.
    Où plutôt un exemple.
    J'ai été recruté il y a un 18 mois dans une boîte sur un existant: grosse base de données avec des procédures stockées kilométriques et site en PHP.
    La philosophie de la cheffe de projet était: aucun check n'est fait car on travaille avec des gens sérieux.
    Ben voyons !

    Aujourd'hui, je dois faire le support de cette m.... sans nom développée par des jeunes. Je précise que dans cette équipe, je suis le plus âgé. J'ai été consultant auparavant et quand je remettais un projet en production, il était testé, code des unit tests à l'appui et validé par milestones avec le client.
    Ce machin a été développé avec certitude que ça marcherait parce que:
    1) les utilisateurs sont gentils et sérieux et ne font aucune erreur (humains + robots, les robots, j'ai confiance, les humains, moins).
    2) on est des bêtes en PL/SQL donc le support sera vite fait bien fait.

    Vous comprenez pourquoi je regarde ailleurs.
    Au passage, je précise que j'ai formé des stagiaires à ma logique de qualité du temps où j'étais consultant et je suis fier de leur accomplissement. Je suis pour que les jeunes mettent les mains dans le cambouis et aillent au bout de leurs idées. Mais il faut un encadrement ! Si le management est incapable de baliser le chemin, vous pouvez être sûr que le projet sera bien piètre.

    @++
    GLDavid
    Consultez la FAQ Perl ainsi que mes cours de Perl.
    N'oubliez pas les balises code ni le tag

    Je ne répond à aucune question technique par MP.

  15. #15
    Membre expert

    Développeur NTIC
    Inscrit en
    Janvier 2011
    Messages
    1 670
    Détails du profil
    Informations personnelles :
    Âge : 33

    Informations professionnelles :
    Activité : Développeur NTIC
    Secteur : Biens de consommation

    Informations forums :
    Inscription : Janvier 2011
    Messages : 1 670
    Points : 3 942
    Points
    3 942
    Par défaut
    Pensez-vous que les universités, les écoles françaises, préparent correctement les étudiants aux métiers du développement logiciel ?
    Certainement pas les universités ...

    Les écoles françaises non plus

    C'est une question d'adaptabilité, en général il faut un voire plusieurs mois, mais, oui, le métier de développeur est autant composé de maintenance de logiciels existants (voir d'améliorations), que de création de logiciels (du moins, c'est ma vision des choses depuis que je suis dans ma boîte).
    L'homme est un fou pour l'homme. Toi qui viens de me mettre un aie au moins le courage d'expliquer pourquoi tu n'es pas d'accord.

  16. #16
    Membre éclairé
    Homme Profil pro
    Enseignant
    Inscrit en
    Décembre 2007
    Messages
    206
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : Suisse

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2007
    Messages : 206
    Points : 849
    Points
    849
    Par défaut
    Personnellement, à part pour de petits projets peut-être, je ne vois pas vraiment de différence entre développement et maintenance. Lorsqu'on travaille sur des applications dont les versions successives s'étendent sur plusieurs années, une nouvelle version contient du nouveau développement et des améliorations de fonctionnalités existantes, on peut donc voir le travail comme du développement ou de la maintenance. Et même lorsque le projet n'est pas très grand, en utilisant une méthode agile, une partie du travaille consiste en la refactorisation du code existant ce qui peut être vu comme de la maintenance. Dans un cas comme dans l'autre, on a un projet avec un début connu, une fin qui devrait l'être et entre deux on fait de la conception et de la programmation.

    Comme j'ai également travaillé dans une équipe de support de 3ème niveau chargée de la gestion des problèmes, là le travail est un peu différent; il s'agit de rechercher les causes des problèmes et soumettre des propositions de solutions aux équipes de développement, mais il ne s'agit pas de maintenance non plus

  17. #17
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    61
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France

    Informations forums :
    Inscription : Mai 2006
    Messages : 61
    Points : 33
    Points
    33
    Par défaut Hum
    Mon baggage universitaire (jusqu'au master) m'a donné tous les outils dont j'ai besoin, des tests unitaires en passant par UML, conventions de nommage, code DRY, différents langages de modélisation, différents langages de développement...

    La seule chose à laquelle je n'étais pas pret était le code qui n'avait pas de tests automatisé, pas de modèle conceptuel écrit, pas de documentation, super copié collé, pas MVC avec des fonctions de plus de 1000 lignes. Enfin bon, je profite des maintenances pour rendre le code plus maintenable quand je modifie pas mal de choses à meme endroits.

  18. #18
    Membre averti
    Homme Profil pro
    DevOps AWS
    Inscrit en
    Juillet 2009
    Messages
    120
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : DevOps AWS
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2009
    Messages : 120
    Points : 334
    Points
    334
    Par défaut
    Comme toujours on trouve de bon sujet sur Développez

    Je me sens concerné par le sujet puisque je rentre en 5ème année et je commence à toucher au bout de mes études, ou plutôt leur commencement.

    Je pense que l'informatique est bien trop vaste pour aborder tous les sujets durant ses études. Comment former une personne sur une techno/pratique sans un projet qui va avec pour lui démontrer l'intérêt de cette techno/pattern/gdb/etc

    On est dans un domaine où nous sommes en formation continu et où les pratiquent des professionnels sont aussi nombreuses que le les lignes de code d'un projet.

    Si je regarde aujourd'hui, je sais que je maitrise seulement les bases de Visual Studio même si je suis bien conscient de l'étendue des possibilités offertes. Pourtant, je ne les verrais surement jamais sauf si un projet m'amène à m'y intéresser. C'est tellement vaste que prendre un bout arbitrairement pour commencer peut amener à rater l'essentiel.

    A mes yeux, le métier de développeur est difficilement enseignable et oblige à faire des choix restrictif sur ce qui est enseigné. Du coup on se retrouve forcement avec des désaveux lors de notre entrée sur le marché du travail. Il nous manque toujours LA techno que l'entreprise recherche (parmi les 15/20 citées dans l'annonce, évidement).

    Du coup, comment faire pour satisfaire le besoin de formation toujours plus pointu et hétérogène avec des compétences croisées ?

    Edit : quand je parle de techno, j'englobe aussi les outils ... dedans ^^ C'est les techno au sens large du thème.

  19. #19
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 603
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par LordMacharius Voir le message
    Du coup, comment faire pour satisfaire le besoin de formation toujours plus pointu et hétérogène avec des compétences croisées ?
    Par justement ne pas enseigner des choses pointues, mais des choses génériques, une manière de penser, d'analyser, un esprit critique, et surtout du bon sens et de la logique...

    Dans les autres domaines que l'info, un ingénieur est à peu près équivalent à un Docteur parce que on sait qu'il n'est pas opérationnel, mais on sait qu'il peut apprendre à l'être en 6 mois.

    Parce qu'on lui a enseigné une manière de réfléchir, plus les bases.

    Vouloir faire des gens "immédiatement sur le marché" est la clé de l'échec, car les technos bougent... Alors que le fond reste...

    Culture générale et des concepts de base plutôt que telle ou telle méthodo, tel ou tel langage...

    D'où la remarque par rapport au debugger : ne pas savoir se servir de tel ou tel outil, ça s'apprend suivant l'outil... Raisonner pour débugger, c'est de la logique et de l'analyse, quel que soit l'outil (ou sans).
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  20. #20
    Membre expert

    Développeur NTIC
    Inscrit en
    Janvier 2011
    Messages
    1 670
    Détails du profil
    Informations personnelles :
    Âge : 33

    Informations professionnelles :
    Activité : Développeur NTIC
    Secteur : Biens de consommation

    Informations forums :
    Inscription : Janvier 2011
    Messages : 1 670
    Points : 3 942
    Points
    3 942
    Par défaut
    Citation Envoyé par LordMacharius Voir le message
    Comment former une personne sur une techno/pratique sans un projet qui va avec pour lui démontrer l'intérêt de cette techno/pattern/gdb/etc ?
    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.

    Voilà pourquoi le métier est intéressant, on ne fera pas la même chose toute notre vie. Et je plains ceux qui ne se tiennent pas à jour et qui seront dépassés dans 2 ans ...
    L'homme est un fou pour l'homme. Toi qui viens de me mettre un aie au moins le courage d'expliquer pourquoi tu n'es pas d'accord.

Discussions similaires

  1. Les étudiants sont-ils bien formés à la réalité des métiers du développement logiciel?
    Par mattj dans le forum Débats sur le développement - Le Best Of
    Réponses: 88
    Dernier message: 04/09/2012, 01h40
  2. mes messages sont-ils bien envoyés?!
    Par bouzaidi dans le forum C++
    Réponses: 0
    Dernier message: 23/08/2007, 11h24
  3. Réponses: 2
    Dernier message: 06/05/2007, 23h37
  4. Réponses: 1
    Dernier message: 04/04/2007, 14h43
  5. Les événement sont-ils synchrones ?
    Par fregolo52 dans le forum Framework .NET
    Réponses: 1
    Dernier message: 27/09/2006, 17h44

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo