Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Patrick Ruiz

136PARTAGES

18  2 
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


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.


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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 18/10/2019 à 16:59
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.
5  0 
Avatar de Angelsafrania
Membre confirmé https://www.developpez.com
Le 18/10/2019 à 9:55
Les tests automatisés !
Apprendre les différents types de tests automatisés existant, apprendre à en écrire des pertinents.
6  2 
Avatar de pboulanger
Membre confirmé https://www.developpez.com
Le 18/10/2019 à 10:30
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...
6  2 
Avatar de Gnomial
Futur Membre du Club https://www.developpez.com
Le 18/10/2019 à 11:10
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.
3  1 
Avatar de iclo
Membre du Club https://www.developpez.com
Le 21/10/2019 à 10:12
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é.
1  0 
Avatar de Gunny
Membre averti https://www.developpez.com
Le 28/10/2019 à 9:35
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.
1  0 
Avatar de JeanYvette
Membre actif https://www.developpez.com
Le 29/10/2019 à 14:46
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 !
1  0 
Avatar de IFA2377
Membre actif https://www.developpez.com
Le 05/11/2019 à 20:56
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.
1  0 
Avatar de iclo
Membre du Club https://www.developpez.com
Le 18/10/2019 à 15:29
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.
0  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 21/10/2019 à 11:06
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.
0  0