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. #61
    Membre habitué
    Inscrit en
    Octobre 2004
    Messages
    83
    Détails du profil
    Informations forums :
    Inscription : Octobre 2004
    Messages : 83
    Points : 132
    Points
    132
    Par défaut
    Citation Envoyé par arkhamon Voir le message
    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 Voir le message
    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 Voir le message
    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

  2. #62
    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 Zweet Voir le message
    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 Voir le message
    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 Voir le message
    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".
    Matthias
    Chef de projet et développeur
    http://matthiasjouan.fr/

  3. #63
    Membre éprouvé

    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    Janvier 2006
    Messages
    621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : Janvier 2006
    Messages : 621
    Points : 1 264
    Points
    1 264
    Par défaut
    Citation Envoyé par mattj Voir le message
    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...
    "L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
    Général George S. PATTON. Messine 1943.

  4. #64
    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
    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...
    "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

  5. #65
    Membre éprouvé

    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    Janvier 2006
    Messages
    621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : Janvier 2006
    Messages : 621
    Points : 1 264
    Points
    1 264
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    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 Voir le message
    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...
    "L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
    Général George S. PATTON. Messine 1943.

  6. #66
    Traductrice
    Avatar de Mishulyna
    Femme Profil pro
    Développeur Java
    Inscrit en
    Novembre 2008
    Messages
    1 504
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2008
    Messages : 1 504
    Points : 7 840
    Points
    7 840
    Par défaut
    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.
    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!
    Chaque fois que tu dis "je ne peux pas", n'oublie pas d'ajouter le mot "encore".

  7. #67
    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
    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...
    Matthias
    Chef de projet et développeur
    http://matthiasjouan.fr/

  8. #68
    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
    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 :

    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..
    "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

  9. #69
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    Très bon paragraphe
    Comme dit partiellement dans cette vidéo : .

  10. #70
    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
    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
    "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

  11. #71
    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
    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.....

    A voir, il y a sans doute 1000 raisons de ne pas le faire. Mais ce genr d'idée cruelle me plait beaucoup.
    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.

  12. #72
    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
    Citation Envoyé par el_slapper Voir le message
    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.....

    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.
    --- Sevyc64 ---

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

  13. #73
    Membre éprouvé

    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    Janvier 2006
    Messages
    621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : Janvier 2006
    Messages : 621
    Points : 1 264
    Points
    1 264
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    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.....

    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 !
    La pédagogie par la découverte...

    Au fait, j'adore ta signature...
    "L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
    Général George S. PATTON. Messine 1943.

  14. #74
    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 el_slapper Voir le message
    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.....

    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
    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.

  15. #75
    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 Zweet Voir le message
    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
    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 ).

    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.
    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.

  16. #76
    Membre éprouvé

    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    Janvier 2006
    Messages
    621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : Janvier 2006
    Messages : 621
    Points : 1 264
    Points
    1 264
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    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...
    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...
    "L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
    Général George S. PATTON. Messine 1943.

  17. #77
    Membre à l'essai
    Homme Profil pro
    Technicien Help Desk
    Inscrit en
    Novembre 2007
    Messages
    9
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : Belgique

    Informations professionnelles :
    Activité : Technicien Help Desk
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Novembre 2007
    Messages : 9
    Points : 14
    Points
    14
    Par défaut
    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

  18. #78
    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 el_slapper Voir le message
    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

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

    Du style :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    toto ( int a, int b, double c )
    {
    ...
    }
    
    ....
    toto1(1,2);
    Dans le code, et

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    #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



    Citation Envoyé par goudax Voir le message
    "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


    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é...
    "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

  19. #79
    Membre éprouvé

    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    Janvier 2006
    Messages
    621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : Janvier 2006
    Messages : 621
    Points : 1 264
    Points
    1 264
    Par défaut
    Citation Envoyé par goudax Voir le message
    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 Voir le message
    En espérant que vous trouverez mon intervention pertinente
    Ouais j'ai même "plussé" (Dieu que j'aime pas ce mot là)...
    "L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
    Général George S. PATTON. Messine 1943.

  20. #80
    Membre éprouvé

    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    Janvier 2006
    Messages
    621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : Janvier 2006
    Messages : 621
    Points : 1 264
    Points
    1 264
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    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
    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 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 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... ?
    "L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
    Général George S. PATTON. Messine 1943.

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