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

Débats sur le développement - Le Best Of Discussion :

Quelles sont les choses qu’on devrait enseigner aux développeurs à l’université ?


Sujet :

Débats sur le développement - Le Best Of

  1. #1
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Redacteur web
    Inscrit en
    février 2017
    Messages
    814
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Redacteur web
    Secteur : Communication - Médias

    Informations forums :
    Inscription : février 2017
    Messages : 814
    Points : 27 945
    Points
    27 945
    Par défaut Quelles sont les choses qu’on devrait enseigner aux développeurs à l’université ?
    Quelles sont les choses qu’on devrait enseigner aux développeurs à l’université ?
    L’auteur de la plateforme Binaris passe en revue une liste non exhaustive d’aspects

    De façon traditionnelle, l’exercice en tant que professionnel de l’informatique en général est conditionné par le passage du postulant par une formation qui mène à un diplôme dans le domaine. La France est un bel exemple de ces pays où l’accès à bon nombre de postes de développeur informatique nécessite de présenter au futur employeur un parchemin qui correspond à 4 années d’études supérieures à minima (bac+4, bac+5, doctorat, etc.).

    L’obtention d’un emploi nécessite de faire valoir le diplôme adéquat ou du moins celui que le futur employeur mentionne sur l’offre. De façon générale, le cursus universitaire apparaît donc comme une sorte de préparation aux défis qui attendent le postulant sur le terrain. Seulement, l’auteur de la plateforme serverless Binaris lui attribue un certain nombre de tares dont la propension à pencher sur la théorie plutôt que sur des aspects susceptibles de faire de ses produits d’excellents praticiens.

    « Voici quelques-unes des choses que j’aimerais que l’on enseigne à l’université plutôt que de s’appesantir sur de la théorie pure » :

    1. Éviter de baser ses décisions sur le nombre de lignes de code

    Le nombre de lignes de code est l’une des métriques autour desquelles les discussions d’équipes de développement en informatique tournent souvent. Pour un projet donné, il peut être question de savoir s’il est mieux d’avoir une grosse ou une petite base de code (en termes de nombre de lignes de code). Le développement de l’auteur de la plateforme Binaris laisse filtrer que ce type de questionnement est quasi inutile lorsqu’il souligne que « le faire serait similaire à évaluer la qualité d’un livre sur la base du nombre de lignes de code. »

    De façon brossée, il précise qu’il n’est pas nécessaire de compter, mais d’écrire autant de lignes de code que nécessaire tout en restant cohérent avec quelques principes : le code est cohérent ; le code est autodescriptif ; le code est bien documenté ; le code s’appuie sur des fonctionnalités modernes et stables ; le code n’est pas inutilement complexe, etc.

    2. Il n’y a pas de « bons » et de « mauvais » langages de programmation

    Dans un parallèle qu’il établit avec une boîte à outils, il montre que chaque langage de programmation introduit un jeu de compromis avec lequel chaque développeur doit traiter. En d’autres termes, il n’y a pas de
    « bons » et de « mauvais » langages de programmation. Il y aurait simplement un choix à effectuer et même s’il souligne qu’il y a, dans la plupart des cas, peu de situations pour lesquelles le choix du langage est une question cruciale, il dresse une liste de points à prendre en compte pour l’atteinte de cet objectif : la disponibilité des ressources en ligne ; la rapidité de développement ; la tendance à générer des bogues ; la qualité et l’étendue de l’écosystème de bibliothèques ; les performances, etc.

    « Il y a aussi un type d’association que les tendances actuelles suggèrent fortement. Si vous travaillez dans le domaine de la science des données, il serait réaliste d'utiliser Python, R ou Scala (peut-être Java). Si c'est un projet pour passer du temps, utilisez le langage qui vous rendra le plus heureux. Il n'y a qu'une seule règle non négociable sur laquelle je m'appuie. Je refuse d'utiliser des langages qui n'ont pas la plupart des problèmes que je vais rencontrer directement résolus sur StackOverflow. Ce n'est pas que je ne peux pas le résoudre, c'est juste que ce n'est pas la peine d'y consacrer du temps », ajoute-t-il

    Nom : 4.png
Affichages : 9596
Taille : 105,4 Ko

    3. Lire le code d’autres développeurs est une activité difficile

    « Lire le code des autres donne presque l'impression de lire une langue étrangère. Même si vous êtes à l'aise avec le choix du langage de programmation de l'auteur, vous devez quand même vous adapter à différents styles et choix d'architecture. Cela suppose également que l'auteur a écrit un code cohérent et fiable - une cible qui peut être atteinte ou manquée », écrit-il laissant ainsi filtrer que la lecture du code d’autres développeurs n’est pas une activité aisée. Pourtant, c’est une activité qui meuble une bonne partie du quotidien du développeur qui travaille au sein d’une équipe. Il faut arriver à maîtriser cet exercice et le développeur de la plateforme Binaris suggère de faire de la revue de code sur des plateformes comme GitHub pour aiguiser cette aptitude.

    « La seconde astuce qui peut vous aider à lire le code d'autres personnes est un peu plus unique. C'est une technique que j'ai mise au point et elle a vraiment réduit le temps qu'il me faut pour me sentir à l'aise avec du code d'autres développeurs. Après avoir regardé le style du code que je veux lire, je commence par ouvrir vi et à écrire du code dans le style utilisé par le projet. Lorsque vous écrivez du code dans le nouveau style, vous améliorerez également vos compétences en lecture. Le style vous semblera moins étranger, comme vous l'avez déjà expérimenté. Même lorsque je parcours un projet aléatoire sur Github, je m'y adonne rapidement », ajoute-t-il.

    4. Garder à l’esprit qu’il n’y a pas de code « parfait »

    Dans son billet, l’auteur de la plateforme Binaris a aussi tenu à recadrer l’idée selon laquelle tous les programmeurs en industrie écrivent du code « parfait ». Il insiste sur ceci que même dans ces sphères où l’on a affaire à des programmeurs très expérimentés, le salut passe par les revues de code.

    « Je travaille avec une équipe d'ingénieurs vraiment brillants. Ce sont quelques-uns des programmeurs les plus compétents et les plus confiants dont on puisse s'attacher les services. Chaque membre de notre équipe (y compris moi) aurait une crise de panique totale si quelqu'un suggérait de faire passer du code non révisé. Même si vous pensez être le prochain Bill Gates vous ferez des erreurs. Je ne parle même pas d'erreurs logiques, je parle de fautes de frappe, de caractères manquants. Je parle de choses pour lesquelles on a besoin d'une autre paire d'yeux », écrit-il.

    5. Travailler comme développeur ne veut pas dire 8 heures de programmation par jour

    Dans bien de pays au monde, la journée de travail a une durée de 8 heures. Pour un employé de bureau, on arrive au lieu de service, s’installe sur un siège devant un ordinateur et se lance dans ses activités. Mais, lesquelles ? De quoi s’agit-il dans la réalité ? De « 8 heures de travail » ou « 8 heures au travail » ? En d’autres termes, pour combien de temps les travailleurs sont-ils productifs sur une journée de travail ?

    « Très peu de personnes sont capables d’écrire du code pendant plus de 4 heures par jour. Les personnes qui ne sont pas d'accord avec cette affirmation sont soit l'exception à la règle, soit travaillent dans des entreprises qui devraient mieux les traiter. La programmation est une tâche exigeante sur le plan mental. Il est tout à fait déraisonnable de s'attendre à ce que quelqu'un écrive du code 8 heures par jour, 5 jours par semaine. », répond l’auteur de la plateforme Binaris dans son billet de blog.

    Un sondage d’Invitation Digital Ltd – une firme de marketing basée au Royaume-Uni – paru en début d’année met en lumière des tendances similaires : la durée moyenne de productivité sur le lieu de service est de 2 h 53 min, soit moins de 3 h.

    Nom : 5.png
Affichages : 1932
Taille : 259,9 Ko

    Il s’agit d’un avis avec des points susceptibles de faire débat. Par exemple, il semble difficile d’imaginer une formation de niveau universitaire au cours de laquelle l’on n’enseigne pas aux étudiants qu’il n’y a pas de « bons » et de « mauvais » langages de programmation ou encore que lire le code d'autres intervenants dans la filière n'est pas une activité aisée. Cela reste néanmoins une contribution aux questionnements liés aux habitudes que les travailleurs de la filière programmation informatique doivent avoir.

    Source : billet de blog

    Et vous ?

    Les aspects que soulèvent l’auteur de la plateforme Binaris font-ils vraiment défaut aux cursus de formations universitaires en informatique ?

    Êtes-vous issu d’une formation universitaire en informatique ? Si oui, lui reconnaissez-vous ces tares ?

    Quels sont d’après vous les choses que l’on devrait enseigner aux développeurs à l’université ?

    Voir aussi :

    Qu'est-ce qui fait un bon programmeur ? Un senior liste cinq caractéristiques d'un bon programmeur

    Faut-il éliminer le mythe du programmeur génie ? Selon un sénior, « la plupart des gens sont moyens » et cela n'est pas grave

    Le talent et la passion suffisent-ils pour faire un bon développeur ? Les créateurs de Django, PHP et Rails n'étaient pas des passionnés du code

    Tout le monde ne peut pas devenir développeur, il faut d'abord disposer de certains prérequis
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre confirmé

    Homme Profil pro
    Développeur Java
    Inscrit en
    février 2007
    Messages
    163
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Distribution

    Informations forums :
    Inscription : février 2007
    Messages : 163
    Points : 630
    Points
    630
    Par défaut
    Les tests automatisés !
    Apprendre les différents types de tests automatisés existant, apprendre à en écrire des pertinents.
    L'expérience est une lanterne que l'on porte sur le dos et qui n'eclaire jamais que le chemin parcouru.

    La nature fait les choses sans se presser, et pourtant tout est accompli.

  3. #3
    Membre confirmé
    Homme Profil pro
    Consultant informatique
    Inscrit en
    décembre 2008
    Messages
    72
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : décembre 2008
    Messages : 72
    Points : 634
    Points
    634
    Par défaut
    Des cours d'algorithmes, on retrouve beaucoup trop de 'développeurs' ne sachant pas choisir la structure de données adaptées à son problème ou l'algorithme adapté... Comprendre la différence en une std::map et un std::unordered_map par exemple en terme de performance mais aussi en consommation mémoire... etc...

    On retrouve de plus en plus de développeurs très fort en coding game mais incapable de s'adapter à un problème qu'ils n'ont pas étudié précédemment. Je me souviens d'un collègue; qui pour un parcours d'une structure de données arborescente, avait implémenter 3 boucles for imbriquées (le concept de la récursivité lui était étranger....

    L'apprentissage d'un langage pure fonctionnel est un plus...

  4. #4
    Futur Membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2019
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 22
    Localisation : France, Haute Garonne (Midi Pyrénées)

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

    Informations forums :
    Inscription : juillet 2019
    Messages : 2
    Points : 6
    Points
    6
    Par défaut
    Sortant tout juste d'un cursus universitaire, je me permets de donner mon point de vue.

    1. Éviter de baser ses décisions sur le nombre de lignes de code
    L'auteur a bien raison, on nous chambre en permanence sur le nombre de lignes de code. Je pense qu'il faut faire la balance entre performances et maintenabilité. Le problème est que la compétition innée dans les cursus de programmation est :

    1 - Le premier qui finira à écrire son algorithme (donc en négligeant toutes les règles de qualité du code)
    2 - Celui qui aura écrit le moins de lignes de codes (quitte à se retrouver avec des if else (habituellement écrits sur 4 lignes) rédigés sur 1 seule ligne mais incompréhensibles)

    Et je pense que ces "unités de mesure" viennent principalement du fait que les algorithmes que l'on écrit en cours ne sont jamais très conséquents et tournent toujours plus ou moins rapidement et qu'il n'y a pas d'utilisateur final, à tel point que mesurer la performance paraît inutile (et implicitement la maintenabilité). Mais également du fait que aucun outil pour mesurer les performances ne sont enseignés aux élèves. Lors de ma 1ère année de Licence, nous programmions en Ada et la moitié des programmes des élèves n'étaient pas indentés. Le seul objectif était de produire un algorithme fonctionnel.
    Seulement lorsque tu rentres dans la "vraie vie" d'un programmeur, tu te rends comptes que tu as un résultat à produire auprès du client et que la performance et la maintenabilité font partie des premiers critères.


    3. Lire le code d’autres développeurs est une activité difficile
    Quand le développeur écrit son programme, il a son propre "environnement de réflexion". Soit il a créé le code de A à Z, soit il a déjà pris connaissance du code précédent (et si ce n'est ni l'un ni l'autre, chapeau ). Il est donc implicite que la personne qui va relire le code n'aura pas la même réflexion et la même image d'ensemble du code que le développeur précédent. Un code qui peut nous paraître simple à "déchiffrer" peut paraître tout aussi compliqué à autrui. Je pense que peu importe qui écrit du code, il sera toujours difficilement intégrable à notre propre réflexion.
    C'est comme décrire un endroit que tu as visité le mois dernier à Châteauroux: tu as l'image d'ensemble, tu sais à quoi ça ressemble.. mais la personne en face s'en fout cherchera à s'imaginer l'endroit et ça ne ressemblera jamais exactement à ce que tu essaies de décrire.

    4. Garder à l’esprit qu’il n’y a pas de code « parfait »
    J'associe toujours l'écriture du code à l'écriture d'un livre ou la création d'une oeuvre d'art... Existe t-il vraiment des critères pouvant définir ce qu'est un code parfait ? Outre les critères de performances, ce sera toujours plus ou moins subjectif. Michel adore les boucles while, alors que Jacquie préfère les boucles for avec un exit. Qui a raison ?

    5. Travailler comme développeur ne veut pas dire 8 heures de programmation par jour
    Et pour n'importe quel métier, honnêtement. Je pense qu'il faut simplement faire attention à notre "passion" pour la programmation et ne pas se laisser prendre au piège pour que l'on en fasse plus sous prétexte que cela nous plaît. Personnellement, j'aime la programmation, mais pas au point que ce soit ma passion (ou du moins pas ma première passion) et je pense que ça m'aide à équilibrer ma vie au travail. Mais ça ne m'empêche pas de m'appliquer (et de m'impliquer) dans mon travail.

  5. #5
    Membre du Club
    Profil pro
    Consultant
    Inscrit en
    novembre 2003
    Messages
    11
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Consultant

    Informations forums :
    Inscription : novembre 2003
    Messages : 11
    Points : 57
    Points
    57
    Par défaut
    Bonjour,

    Les formations actuelles manquent souvent de bonnes bases algorithmiques et de méthodologies de développements et de tests.
    J'en suis arrivé quand je fais passer des tests techniques lors d'un recrutement à demander un pseudo code pour trier un simple tableau de 5 nombres entiers. Les 3/4 des candidats diplômés ou sur le point de l'être sont incapables de sortir ne serait-ce qu'une base de programme.

    Il serait plus judicieux d'insister pendant les études sur des bases intemporelles, et surtout à apprendre "à apprendre par soi même" que de vouloir former des gens sur des outils / framework/ technologies précises qui auront soit disparu quelques années après ou bien mutées à un point qu'il aura fallu se former pour rester compétent.

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 5 892
    Points : 26 939
    Points
    26 939
    Par défaut
    La maintenance. Les foutre sur des vieux codes pourris, avec plein de couches de maintenances différentes qui puent.... Mais qui marchent comme du papier à musique. Et leur faire faire une petite modif, comme ça, juste pour rigoler.

    Sinon, l'autre truc que j’aimerais de la part des établissements de formation, c'est de ne pas diplômer les gens qui n'ont pas le niveau. Mais bon, vœu pieux.
    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
    Membre éclairé
    Homme Profil pro
    Programmeur du dimanche
    Inscrit en
    août 2017
    Messages
    212
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Programmeur du dimanche
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2017
    Messages : 212
    Points : 673
    Points
    673
    Par défaut
    Bon, en général, celui qui prétend m'imposer ce que je dois enseigner, je lui fais bouffer ses lunettes et ses couilles.

    Mais je plussoie à 1000% le post de el_slapper.

  8. #8
    Membre du Club
    Profil pro
    Consultant
    Inscrit en
    novembre 2003
    Messages
    11
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Consultant

    Informations forums :
    Inscription : novembre 2003
    Messages : 11
    Points : 57
    Points
    57
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    Sinon, l'autre truc que j’aimerais de la part des établissements de formation, c'est de ne pas diplômer les gens qui n'ont pas le niveau. Mais bon, vœu pieux.
    Je suis en effet souvent sidérer par le niveau de certains candidats : il est tout à fait normal d'avoir encore beaucoup à apprendre (nous en sommes tous là durant l'ensemble de notre carrière) mais quand le "bootstrap" du développement n'est pas là, ça devient très compliqué.

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 5 892
    Points : 26 939
    Points
    26 939
    Par défaut
    Citation Envoyé par iclo Voir le message
    Je suis en effet souvent sidérer par le niveau de certains candidats : il est tout à fait normal d'avoir encore beaucoup à apprendre (nous en sommes tous là durant l'ensemble de notre carrière) mais quand le "bootstrap" du développement n'est pas là, ça devient très compliqué.
    J'ai dit vœu pieux, d'ailleurs, parce-que plusieurs forces concourent à cette situation :

    • Le marché est demandeur de jeunes diplômés - pour peu qu'il y aie marqué "informatique" sur le diplôme
    • les recruteurs sont mal armés pour détecter les gens qui ne savent pas faire un fizzbuzz
    • les formations sont ambiguës : on prépare des "data scientists" ou des "ingénieurs qui passeront vite chef de projet", pas des développeurs
    • la tradition veut qu'on juge les gens sur les maths plus qu'autre chose
    • l'habitude du corps professoral de juger les élèves sur des exercices standard, pas sur des exercices un peu vicieux(et donc réalistes). Bon, ce n'est pas vrai pour tous, mais c'est bien répandu
    • (et sans doute encore d'autres)


    Donc voilà, des gens qui n'ont pas la tournure d'esprit nécessaire pour faire un code qui sortent d'un micropoil des exemples standard, on en trouve bien avec un beau diplôme, et on ne peut rien en faire. Et ils inondent les SSII, et donc, fatalement, les grands comptes. Et en plus on leur a fait croire qu'ils ne feraient que de beaux projets, là ou la réalité du terrain est nettement plus moche. J'avais un avantage immense, au final. On m'avait dit "ton boulot, ça sera probablement de récupérer un atelier avec 20/30 presses à injecter dedans, qui tourne nickel, et à arriver à faire mieux quand même. C'est moche, c'est sale, on se salit vite les mains, mais les pièces sortent propres, on ne sait pas par quel miracle, mais comme c'est de l'alimentaire, c'est nécessaire. Et tu dois améliorer la productivité. Ton budget est dérisoire. Bon courage.".

    Une bien meilleure préparation(a minima psychologiquement) que d'enquiller les projets sur les mille et une manières de faire un tri de la manière la plus élégante possible. C'était bien plus réaliste, et chercher à améliorer la vitesse de changement d'un moule à injection de seau pour l'emballage(pour y mettre du yaourt ou de la peinture à numéroter les moutons, authentique), ou encore à réduire le nombre de rebuts, ressemblait sans doute plus à la maintenance d'un vieux batch COBOL qui calcule et prépare l'impression de votre montant d'assurance automobile qu'un projet informatique page blanche sur une théorie scientifique rigolote. Même si ça n'était pas de l'informatique du tout.
    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.

  10. #10
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    YYYY
    Inscrit en
    mai 2002
    Messages
    19 198
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : YYYY
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 19 198
    Points : 45 375
    Points
    45 375
    Par défaut
    Citation Envoyé par pboulanger Voir le message
    ... Je me souviens d'un collègue; qui pour un parcours d'une structure de données arborescente, avait implémenter 3 boucles for imbriquées (le concept de la récursivité lui était étranger....
    D'autant plus que tout code récursif peut être "dérécursivé" par l'usage d'une pile (théorème mathématique découvert par un mathématicien italien dans la seconde moitié du 20e siècle....). Et c'est évidemment beaucoup plus performant (en pratique, utilisé dans les bons SGBDR comme Oracle ou SQL Server pour piloter les arbres BTree des index...).

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  11. #11
    Membre du Club
    Femme Profil pro
    Architecte technique
    Inscrit en
    août 2019
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 22
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte technique

    Informations forums :
    Inscription : août 2019
    Messages : 14
    Points : 43
    Points
    43
    Par défaut
    La premiere chose a leur enseigner c'est ceci :

    https://www.developpez.net/forums/d2...E#post11189675

  12. #12
    Membre régulier Avatar de abdennour bouaicha
    Homme Profil pro
    Développeur Java
    Inscrit en
    avril 2009
    Messages
    87
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Maroc

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : avril 2009
    Messages : 87
    Points : 92
    Points
    92
    Par défaut
    a mon avis il faut enseigner si qui est demandé dans le marche ,
    je connais des étudiants ingénieurs en informatique n' ont plus vue le javascript dans l’école , et lors du stage fin d’étude ils ont soufrai.

  13. #13
    Membre averti Avatar de Gunny
    Homme Profil pro
    Développeur Web
    Inscrit en
    avril 2007
    Messages
    161
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Danemark

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : avril 2007
    Messages : 161
    Points : 409
    Points
    409
    Par défaut
    J'ai appris tout ça à l'Université personnellement...
    Par contre, ce que je regrette n'avoir pas appris alors qu'on s'en sert tout le temps (je suis sorti en 2010, ça a peut-être changé depuis) :
    - Tests automatisés : ok, j'ai eu un seul module, ça a servi d'introduction technique, mais après, plus rien. Or le plus important et le plus difficile c'est de réfléchir à quels tests écrire, et comment les écrire.
    - Contrôle de source : je n'ai simplement jamais utilisé de logiciel de contrôle de source durant mes études. C'est incroyablement important quelle que soit la taille du projet (même un tout petit projet perso).
    - Travail en équipe, code review, maintenance, refactoring : cela compte pour au moins la moitié du travail d'un dev.


    Je pense que se focaliser sur les technologies que "le marché" cherche est une erreur, il faut voir un niveau au dessus. Être un bon développeur c'est posséder de solides bases en programmation (algorithmique, bases de données, réseaux), mais aussi beaucoup de méta-compétences : capacité d'adaptation, rigueur, curiosité, etc. Les technologies en elles-même importent peu car elles changent tout le temps et s'apprennent vite.

  14. #14
    Membre actif
    Homme Profil pro
    developpeur sql et scripting
    Inscrit en
    août 2014
    Messages
    170
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : developpeur sql et scripting
    Secteur : Santé

    Informations forums :
    Inscription : août 2014
    Messages : 170
    Points : 283
    Points
    283
    Par défaut
    J'ai vu plusieurs commentaires parler de cours d'algorithmie, il en est en effet réellement important. Combien de fois j'ai vu des gens venir me demander de les aider sur quelque choses en pensant qu'ils avaient moins de compétences là où au final, le problème venait simplement de l'algo.
    Certains veulent tuer une mouche avec un bazooka et donc se retrouvent avec des besoins beaucoup trop élevés...

    Apprendre, par la même, à faire un code simplifié, qui est souvent synonyme d'un algo simple ou au moins simplifié.

    Un problème majeur que je retrouve est... le copier/coller. Certains s'en sortent grâce à un petit coup de ctrl + c / ctrl + v... En effet, comme disent certains, un dév "flemmard" est un dev "astucieux (pour expliquer le principe de classes que l'on peut porter sur plein de projet). Mais parfois, il serait bon de savoir comment faire quelque chose voulue DEPUIS ZÉRO, j'ai l'impression que plus le temps passe, plus cela se perd (moi en premier) mais les bases aussi, par conséquent, peuvent se perdre...

    Ensuite, et là c'est la personne qui travaillent pas mal sur les SGBD qui donne un exemple de ce qu'il croise quotidiennement, il faut arrêter de commencer l'enseignement/prise en main avec des outils de style TOAD. Je m'explique (Ceci est un exemple que l'on peut retrouver dans d'autres domaines):
    "Vous voulez la liste des tables qui contiennent le mot xxx dans son nom ?"
    => "Lancez TOAD est faites une recherche dans les noms d'objets via le menu machin"
    "Vous cherchez la liste des procédures qui font appel/utilisent une table spécifique ?"
    => "Lancez TOAD et cherchez dans les textes des objets via le menu truc"
    Conclusion : Les gens ne connaissent pas/plus les tables systèmes et un moment ça devient gênant. Alors bien sûr qu'ne fois qu'on sait le faire en requête, que l'on sait comment ça fonctionne "derrière" utiliser un outils comme cela fait gagner du temps, mais il ne faut pas que ça soit au détriment de connaissance de bases
    => Des outils oui, pour gagner du temps oui, pour perdre nos connaissances, non !

  15. #15
    Membre actif Avatar de IFA2377
    Homme Profil pro
    Développeur Gestion (Retraité)
    Inscrit en
    novembre 2007
    Messages
    155
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 72
    Localisation : France, Côtes d'Armor (Bretagne)

    Informations professionnelles :
    Activité : Développeur Gestion (Retraité)
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : novembre 2007
    Messages : 155
    Points : 252
    Points
    252
    Par défaut Apprendre par soi-même
    Citation Envoyé par iclo Voir le message
    Il serait plus judicieux d'insister pendant les études sur des bases intemporelles, et surtout à apprendre "à apprendre par soi même" que de vouloir former des gens sur des outils / framework/ technologies précises qui auront soit disparu quelques années après ou bien mutées à un point qu'il aura fallu se former pour rester compétent.
    D'un côté, il est enseigné une technicité dans une forme pédagogique et de l'autre les étudiants ne viennent pas chercher du grain à moudre mais des recettes. Tout va bien donc, l'offre répond à la demande, sauf que cela contribue à former des Ouvriers Spécialisés et non des ingénieurs autonomes, à l’esprit ouvert, en quête de réflexion.

  16. #16
    Membre actif Avatar de IFA2377
    Homme Profil pro
    Développeur Gestion (Retraité)
    Inscrit en
    novembre 2007
    Messages
    155
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 72
    Localisation : France, Côtes d'Armor (Bretagne)

    Informations professionnelles :
    Activité : Développeur Gestion (Retraité)
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : novembre 2007
    Messages : 155
    Points : 252
    Points
    252
    Par défaut À propos de forme pédagogique et d’algorithmique
    Citation Envoyé par Gnomial Voir le message
    Sortant tout juste d'un cursus universitaire, je me permets de donner mon point de vue.

    … Je pense que les algorithmes que l'on écrit en cours ne sont jamais très conséquents et tournent toujours plus ou moins rapidement et qu'il n'y a pas d'utilisateur final, à tel point que mesurer la performance paraît inutile (et implicitement la maintenabilité). Mais également du fait qu’ aucun outil pour mesurer les performances ne sont enseignés aux élèves. Lors de ma 1ère année de Licence, nous programmions en Ada et la moitié des programmes des élèves n'étaient pas indentés. Le seul objectif était de produire un algorithme fonctionnel.

    Seulement lorsque tu rentres dans la "vraie vie" d'un programmeur, tu te rends comptes que tu as un résultat à produire auprès du client et que la performance et la maintenabilité font partie des premiers critères.
    Forme pédagogique

    C’est ce que j’ai appelé « Enseigner une technicité dans une forme pédagogique » dans mon précédent post.

    Le savoir-faire ne s’enseigne pas… Sauf une fois… mais il faut dire que le formateur était en fait un professionnel indépendant qui enseignait à l’IUT pour pouvoir l’indiquer sur sa carte de visite.

    C’était dans le cadre d’un DUT en formation continue dans les années 80.

    Ses cours d’analyse revêtaient une forme quasi philosophique que je paraissais être le seul à comprendre. Il n’a par exemple jamais prononcé le terme « Merise ». Son discours était un régal intellectuel mais manifestement pas pour tout le monde. Certains de mes collègues, pourtant des professionnels en principe expérimentés comme moi, manifestaient leur incompréhension totale. C’est là que j’ai compris qu’ils attendaient des recettes. Ils ont gâché la chance qu’ils avaient qu’un professionnel fabuleux leur demande de réfléchir et non justement d’appliquer des recettes. Ses DST, intelligents, professionnels, demandaient de la réflexion. Ses corrections étaient de véritables psychanalyses. Il expliquait mieux que je ne l’aurais fait moi-même, mon approche intellectuelle de ses DST. Un régal pour moi mais un grand désarroi pour d’autres.

    Une solution serait peut-être d’inviter des professionnels à venir partager leur savoir-faire.

    Une autre solution serait peut-être d’inscrire la formation dans le cadre d’une vraie application.

    Algorithmique

    L’algorithmie n’est plus ce qu’elle était. C’est aujourd’hui un autre mot pour dire programmation. Ce que l’on dit « algorithme » n’est en fait qu’une séquence de code. Et c’est bien ce que décrit la FAQ du site :

    Qu’est-ce qu’un algorithme ?

    Un algorithme consiste en la spécification d'un schéma de calcul, sous forme d'une suite d'opérations élémentaires obéissant à un enchaînement déterminé.


    L’organigramme que l’on nomme aujourd’hui algorigramme a disparu.

    Le premier cours Introduction aux algorigrammes, Publié le 25 juin 2007, dans l’espace consacré aux Meilleurs cours pour apprendre l’algorithmique, fait référence à une symbolique… des années 60. Quel professionnel utilise cette symbolique pour formaliser visuellement sa démarche algorithmique ?

    Je note toutefois que dans son avant-propos, l’auteur associe « algorithme » et « organigramme » et non « algorithme » et « programme » :

    Avant toute programmation, il est recommandé d'avoir une visualisation du programme qu'on va faire. Pour cela, il faut faire un algorithme ou un organigramme. Le premier a une structure linéaire comme un programme alors que le second permet de bien mieux visualiser les différents blocs du programme, les boucles, les tests.
    …/…
    Les modes de programmation visuelle, qui se développent de plus en plus ressemblent plus à des algorigrammes qu'à un programme. Il est donc important de prendre connaissance dès que possible avec cette schématique.


    Bon !... Je ne connais pas de mode de programmation visuelle. Je passe mon tour sur le sujet.

    Tout ça pour dire que les Meilleures sources algorithmes et les Exercices corrigés pour apprendre l'algorithmique m’ennuient prodigieusement.

    Vierge de tout organigramme (algorigramme), je n’y décèle aucune pédagogie. Les séquences de programmes sont spécifiques d’un langage. Il faudrait donc connaître le langage pour comprendre la démarche.

    L’organigramme dispense de connaître le langage utilisé et ouvre la possibilité de programmer/tester dans le langage que l’on connaît.

    Un constat :

    Compréhension de l'algorithme de calcul de la factorielle

    Citation Envoyé par FrancisTita Voir le message
    Bonsoir à tous je suis un étudiant débutant dans le domaine informatique. Je suis tombé sur un exercice en ligne sur l'algorithmique après plusieurs heures de réflexion dessus j'ai du mal à comprendre

    Pourriez-vous m'expliquer ligne par ligne afin d'éclairer mes zones d'ombres svp!!

    Voici l'algorithme :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    Var n, i, f: entiers
    Début 
    Écrire  "entrez un nombre :" 
    Lire n
    f=1 
    Pour i=2 à n
    f=f*i
    Fin pour
    Écrire "la factorielle est:" F
    Fin
    Ma réponse :

    Visuellement ça donne ça :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
                         ┌─────────────────────┐
                         |        n = ?        |
                  D_PROG |        f = 1        |
                         |        n :: 1       |
                   n<=1  └──────────┬──────────┘  n>1
               ┌───────────────────<?>───────────────────┐
               |                              ┌──────────┴──────────┐
               |                     D_ENTIER |        i = 2        |
               |                              └──────────┬──────────┘
               |                                         ├───────────────────┐  
               |                              ┌──────────┴──────────┐        |
    ┌──────────┬──────────┐                   |        f = f * i    |        |  
    |       MESSAGE       |          T_ENTIER |        i = i + 1    |        |  
    └──────────┬──────────┘                   |        i :: n       |        |
               |                              └──────────┬──────────┘  i<=n  |  
               |                                        <?>──────────────────┘
               |                              ┌──────────┴──────────┐
               |                     F_ENTIER | « Factorielle = » f |
               |                              └──────────┬──────────┘
               └────────────────────┬────────────────────┘
                         ┌──────────┴──────────┐
                  F_PROG |          Ø          |
                         └─────────────────────┘

Discussions similaires

  1. [Emploi] Quelles sont les raisons des faibles salaires des développeurs 3D ?
    Par Garvelienn dans le forum Développement 2D, 3D et Jeux
    Réponses: 6
    Dernier message: 14/02/2019, 14h31
  2. Quelles sont les entreprises qui contribuent le plus aux projets open source ?
    Par Michael Guilloux dans le forum Logiciels Libres & Open Source
    Réponses: 8
    Dernier message: 04/03/2018, 22h09
  3. Réponses: 7
    Dernier message: 12/10/2013, 17h41
  4. Quelles sont les distibutions avec le kernel 2.4.x.x?
    Par barucca dans le forum Administration système
    Réponses: 7
    Dernier message: 01/04/2004, 16h44
  5. [CR][Jetform] Quelles sont les différences ?
    Par littlecow dans le forum SAP Crystal Reports
    Réponses: 2
    Dernier message: 23/07/2002, 12h40

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