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

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 !

Un développeur devrait-il maitriser plusieurs langages de programmation ?
Pour un sénior, c'est une « une mauvaise idée »

Le , par Amine Horseman

48PARTAGES

5  8 
Dans un billet de blog publié sur Core Java Interviews Question, Sam Atkinson, blogueur et directeur de développement à HSBC nous explique son point de vue sur les développeurs polyvalents qui aiment essayer de nouveaux langages et pourquoi c’est « une mauvaise idée » selon lui.

En effet, Sam Atkinson affirme que les langages bien mûrs comme java sont suffisants pour faire le travail, et il n’est pas nécessaire pour un développeur maîtrisant ce langage d’apprendre de nouveaux : cela « va être un cauchemar de maintenance », même si « vous connaissez déjà le langage en question » prévient-il.

« Java est utilisé depuis longtemps et a un ensemble incroyable d'outils et de bibliothèques autour de lui » ajoute Atkinson en citant l’exemple d’IntelliJ. « Un outillage de ce type n’existe pas de façon mature dans les autres [nouveaux] langages [...] Il y a aussi le manque de documentation et de soutien en ligne ». Toutefois, ce n’est pas le fait de maîtriser plusieurs langages qui pose problème selon lui; bien au contraire, il affirme que ceci est « nécessaire » pour avoir un bon CV et que c’est « une excellente façon de changer sa manière de penser concernant le style de codage ». Cependant, ce qui lui pose problème c’est le fait que les développeurs profitent souvent des projets qu’ils réalisent pour apprendre ces nouveaux langages.

Pour illustrer ce dernier point, il cite un article de Yegor Bugayenko, co-fondateur et directeur de technologie à teamed.io, qui avait écrit dans son blog que « chaque projet de logiciel est un business, et nous, les développeurs, sommes ses ressources ». Par conséquent, si on utilise les projets pour apprendre : « ça sera du vol », et un bon gestionnaire de projets ne doit jamais accepter, car « ce n’est pas une école ».

Bugayenko nous explique ensuite que si on contacte un plombier pour installer un système de drainage dans notre maison, et que celui-ci nous dit qu’il n’a jamais travaillé sur une telle tâche, nous n’accepterons jamais de dépenser notre argent pour qu’il puisse se former. De la même façon, en tant que développeurs, « nous voulons apprendre, mais nous ne voulons pas dépenser notre propre argent pour ça. Nous ne voulons pas rester à la maison pendant quelques années pour apprendre toutes les technologies possibles avant d'entrer dans le marché du travail […] Nous voulons apprendre sur le tas ». Or, un programmeur qui ne possède pas les compétences adéquates est « une ressource non fiable » et « aucun projet ne prendrait une telle ressource depuis le début ».

Concernant Sam Atkinson, nous pouvons néanmoins discuter les gains apportés par l’utilisation de nouveaux langages par rapport aux coûts nécessaires à leur apprentissage, et rester toujours prêts à nous reconvertir dans ces langages si cela est plus avantageux.

Source : Article de Sam Atkinson, Article de Yegor Bugayenko

Pensez-vous qu’apprendre plusieurs langages est une mauvaise chose ?
Que pensez-vous de l’avis d’Atkinson et de Bugayenko ?

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

Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 08/04/2015 à 7:39
Les deux articles sont fort différentes l'un de l'autre.

Celui de Yegor Bugayenko, en gros, dit qu'on ne devrait pas avoir à apprendre au cours d'un projet. Point. Celui de Sam Atkinson dit, lui, que Java permet de résoudre tous les problèmes, et est standard, donc aucun autre langage n'est utile.

Je ne suis d'accord avec aucun des deux articles. Le développement est une activité hautement fluide, contrairement à la plomberie prise en comparaison. Si un plombier met une heure à installer un lavabo(chiffre complètement au pif, je n'y connais rien), il mettra à peu près dix heures pour en installer dix similaires. Peut-être 9 et demi avec l'effet d'expérience. Si un développeur met 10 heures à coder un envoi de mail, pour les 9 autres, il réutilise le code, voire l'encapsule, et ne mettra pas beaucoup plus de temps.

Surtout, si on encapsule proprement, on gagne beaucoup de temps pour la suite du projet - et pour la maintenance. Un contenu informatique n'est pas comme un bâtiment, c'est très vivant, et ça change tout le temps. Prendre le temps d'enseigner les spécificités dudit ensemble, ça permet de gagner du temps tout de suite - le programmeur sera plus opérationnel - et plus tard - on aura un ensemble cohérent. Chaque projet est différent, et croire qu'il suffit d'en maitriser un pour maitriser les autres me parait hautement illusoire.

Pour ce qui est du Java, c'est effectivement un langage qui permet de tout faire. Mais la contrepartie est qu'il n'est pas spécifiquement à adapté à tel ou tel besoin. Il est généraliste. Pour des sujets spécialisés, d'autres langages survivent ou même se développent. J'ai souvenir d'un batch comptable réalisé dans une banque de taille moyenne dont les grands chefs rêvaient de "tout Java", et qu'on m'a fait faire en Cobol. Parceque j'étais deux fois moins cher.

Ca ne veut pas dire que Java est toujours un mauvais choix, mais comme toute création humaine, il a ses limites, et affirmer de but en blanc que c'est toujours le bon choix, c'est à la limite de la croyance religieuse.
21  2 
Avatar de Haseo86
Membre éclairé https://www.developpez.com
Le 08/04/2015 à 13:56
Le décalage entre le contenu de votre article et le titre que vous lui donnez est surprenant, pour ne pas dire dérangeant, sans parler de l'amalgame fait entre les deux articles sources.

En gros l'un fait la pub pour son petit langage préféré (langage que j'utilise au quotidien personnellement, avec d'autres, Java ne saurait résoudre tous les problèmes), et l'autre dit que profiter d'un projet de développement pour apprendre n'est pas honnête, parce que ce n'est pas pour ça que le projet est financé.

Donc aucun rapport entre les deux, mais un débat très intéressant en perspective sur l'intérêt/la possibilité d'apprendre sur le tas en développant. Comme ça a déjà été dit dans les commentaires, il est illusoire de penser que l'on ne passera pas une seule seconde à apprendre au cours d'un projet, et que tout nous est déjà connu avant. Même quelqu'un qui fait du Java depuis 10 ans continue à apprendre, ne serait-ce que parce que les langages évoluent, et évoluent rapidement.

Prendre 50% du temps d'un projet de développement pour se former est très certainement discutable, mais penser que 100% de ce temps sera utilisé à coder est illusoire. Dans le cas contraire c'est que le développeur se contente de ses acquis, ce qui est je pense bien plus mauvais que de passer un peu de temps régulièrement à se mettre à jour.
11  2 
Avatar de fatbob
Membre éclairé https://www.developpez.com
Le 08/04/2015 à 14:04
Citation Envoyé par Mouke Voir le message
En excluant HTML/CSS, il est possible aujourd'hui de faire une app web en javascript de à A à Z : frontend avec jQuery, backend avec node.js, db avec MongoDB.

Plutôt me recycler dans la fabrication de fromage.
11  2 
Avatar de fatbob
Membre éclairé https://www.developpez.com
Le 08/04/2015 à 9:45
Moi non plus, je ne suis pas d'accord avec ces articles.
Pour ce qui concerne Java, j'ai essayé et je n'ai jamais réussi à m'y mettre vraiment. J'ai toujours trouvé le développement en java d'une lourdeur sans égale dans les autres langages que j'ai pu tester (peut-être C++ ?). Il est évident que pour un développeur chevronné dans ce langage, ce point doit s'amenuiser avec le temps mais quand même. Pour la lisibilité et la maintenance, pour ma part, je préfère python (de loin).

Par ailleurs, il faudra m'expliquer comment faire une appli web sans utiliser au moins deux langages (sans compter html et css).

Quant à l'apprentissage au cours d'un projet... Je ne vois même pas comment on peut faire pour ne pas apprendre à chaque projet.
Chaque développement un peu trapu entraîne des choix et des expériences qui sont des apprentissages. Ceux qui ne fonctionnent pas bien entraineront d'autres choix la fois d'après qui nécessiteront sans doute également une part d'apprentissage.
Le plombier a des normes fixes (relativement) là où un développeur travaille sur des environnements mouvants. Un développement de deux ans et la base de donnée a de nouvelle fonctionnalités, le framework a changé de version majeure, le langage a évolué notablement et le contrat suivant est déjà signé... Où apprend-on dans ce cas ?

Au contraire de l'article, je pense que le développeur DOIT se former en permanence, sur tous les projets qu'il fait. Ça fait partie intégrante de son boulot. Celui qui ne le fait pas ne peut pas tenir plus de dix ans avant d'être complètement dépassé sauf à considérer que l'apprentissage des techniques du métier sont un loisir. Je ne vois pas pourquoi un client ou un employeur n'aurait pas à se soucier de cette partie du travail. C'est un peu facile de demander des types de bon niveau, formé aux dernières technologies, sans prendre en compte la nécessité pour ces ressources d'une formation véritablement continue.
11  4 
Avatar de TheLastShot
Membre extrêmement actif https://www.developpez.com
Le 08/04/2015 à 11:37
Pour moi ces deux personnes sont probablement des gens qui n'ont absolument jamais travailler eux-même sur des projets réels. Ils ont peut-être géré des projets et dirigé un équipe de développeur. De plus, l'exemple choisi par ce monsieur Yegor Bugayenko montre bien la stupidité de son raisonnement.
Je cite : "si on contacte un plombier pour installer un système de drainage dans notre maison, et que celui-ci nous dit qu’il n’a jamais travaillé sur une telle tâche, nous n’accepterons jamais de dépenser notre argent pour qu’il puisse se former"
C'est totalement absurde. En effet on n'aura probablement jamais un plomber seul pour ce genre de tâche, mais lorsque ceux-ci sont formés c'est évidemment par l'expérience. Et c'est la même chose en programmation, c'est d'ailleurs ce à quoi servent (ou plutôt sont censé servir) les stages en entreprise.

De plus, je trouve qu'il est très important (en tout cas c'est mon point de vue) d'apprendre quelque chose lorsque je travail sur un projet, sinon je ne vois aucun intérêt dans sa réalisation.

En ce qui concerne ce cher Sam Atkinson (dommage, il ne lira probablement pas ceci), je voudrais lui signaler que Java n'est pas (mais pas du tout) le meilleur langage au monde. Il existe plein de concept absent de ce langage (ou apparu très/trop tardivement) tels que la surcharge d'opérateur et les paramètres par défaut, qui me semblent être des concept relativement basique dans le paradigme sur lequel se base Java. Et j’enchaînerais justement sur la chose suivante: il existe beaucoup de paradigmes (POO, fonctionnel, procédural, pour ne citer que les plus connus) et le fait de maîtriser plusieurs langages, basés sur différents paradigmes, permet justement d'enrichir sa culture et de pouvoir appréhender la résolutions de problèmes sous différents angles.

Bref, je déteste quand on essaie de faire croire que le travail de développeur se résume à accomplir une tâche de manière automatique, sans réfléchir, à la manière d'un robot incapable d'étudier les différentes solutions qui s'offrent à lui et incapable d'évoluer. Le vrai problème chez les développeurs, c'est d'être dirigé par ce genre de personne.
11  4 
Avatar de _skip
Expert éminent https://www.developpez.com
Le 09/04/2015 à 9:03
J'ai lu l'article de Sam Atkinson et je pense que son propos sur java fait entièrement du sens. C'est juste qu'il vous est rapporté entièrement sorti de son contexte.

Citation Envoyé par Sam Atkinson
I’m not sure if you’ve noticed, but recently there seems to be an awful lot of noise about the death of Java and the rise of the JVM. Scala, Clojure, Groovy, Jython have all recently gone through being the language choice du jour (Although this great article shows how Java still rules the roost by a long way). More and more projects in these languages are appearing on the job boards and in projects at bigger and bigger companies

But, is this a good thing or not?

As a massive nerd, I love trying new programming languages. New things are shiny. I like shiny. Last year when I started doing the “functional programming principals in Scala” course run by Martin Odersky, the creator of Scala, I was convinced Scala was going to be the answer to all of my Java based problems. “Look ma, the syntax is so much more concise! And now I understand why immutable is so awesome!”. It’s this kind of hedonism which is why more and more projects are getting started in these languages. Bored programmers want to try new things out, and so a new language is brought into the company.

This is a terrible idea.
.
Je vais pas citer tout l'article mais déjà clairement, au vu des langages qu'il cite, il parle des langages pour la JVM!

Donc lorsqu'il en arrive à son argumentaire comme quoi Java est le meilleur choix parmi ceux-ci, c'est pas dans le sens "C++, javascript, php, .net et tout le reste du monde c'est de la merde" comme on pourrait le croire dans les fragments repris en français de ce topic. Déjà en limitant le scope de son affirmation aux langages pour la JVM, son propos a tout de suite moins l'air d'une bêtise, sachant que les langages destinés à produire du bytecode pour la JVM adressent généralement les mêmes besoins et sont dans la plupart des cas *relativement* interchangeables.

En gros ce qu'il dit :

  • Qu'aucun langage pour la JVM n'est aussi bien servi question outillage que java, c'est objectivement assez vrai.
  • Que java c'est globablement du terrain connu et qu'on a des chances de trouver les réponses (forte communauté), c'est vrai
  • Qu'introduire un autre langage comme Scala ou Groovy accroît les risques de maintenance et ne devrait pas être pris à la légère, c'est largement défendable aussi.
  • Qu'il faut donc des arguments vraiment solides pour justifier l'emploi de ces langages alternatifs en entreprise dans le contexte particulier de son projet sous peine que ça vous retombe lourdement dessus en cas de problème, c'est plutôt vrai aussi.


Donc pour commencer, avant de lâcher des pavés du style "Qu'il essaie de faire XX avec son java de merde" ou encore "si on l'écoutait, on ferait du Cobol", franchement allez lire la source.
9  2 
Avatar de tanatiel
Membre régulier https://www.developpez.com
Le 14/04/2015 à 16:30
Citation Envoyé par Laurent 1973 Voir le message

Par contre, faudrait que les SSII aient une vrai politique de formation de ses consultants.
Or, cela a un coût et de toute façon, les développeurs restent pas longtemps: bah il se formeront chez le client en développant le projet !

Et la boucle est bouclé
C'est tellement vrai. La seule vraie formation que j'ai eu dans ma carrière remonte à 15 ans, depuis j'ai toujours eu droit au fameux "pas de formation sans projet"

Alors oui, rien ne vaut la pratique mais tout de même, les SSII sont dans l'extrême pour la plupart. Et j'ai vu plus d'un projet lancé en mode rock'n roll et que c'est au bout de 3 moi de dèv fait par des juniors qu'on se rend compte qu'on a des problèmes de techno non maîtrisée. Parce que connaître un langage ce n'est pas connaître les différents frameworks qui ont été développés dessus, par exemple.
6  0 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 08/04/2015 à 12:26
Un peu outré par les conclusions de cet article :

- un dev qui n'apprend qu'un seul langage se retrouve mis à la porte lorsque ce langage n'est plus à la mode et qu'il n'a pas su se renouveler
- comment fait-on pour se renouveler si l'entreprise nous cloisonne dans un environnement. ( Je parle pour les dev qui ont des enfants et ne peuvent pas se renouveler chez eux au détriment de l'éducation )

« une ressource non fiable » et « aucun projet ne prendrait une telle ressource depuis le début ».
Personnellement, j'ai horreur de ce genre d'élément de language, notamment du mot "Ressource", je le trouve "Déshumanisant".

Bref avec ce genre de considération , beaucoup de DEV quittent la technique pour passer dans le management, c'est une perte considérable !
8  3 
Avatar de kolodz
Modérateur https://www.developpez.com
Le 08/04/2015 à 16:12
En premier lieu, je tiens à noté que cela fait plaisir d'avoir le premier commentaire d'un article qui est allé lire les sources.

En second lieu, les deux articles ont deux problématiques différentes et donc deux points de vue différents. L'article de Sam Atkinson parle principalement des langages alternatifs et utilisations dans des projets professionnels sans bonne raison. Ce qui posera forcement des problèmes de maintenances (Si cela n'en pose pas pendant le projet en lui-même). L'article de Yegor Bugayenko, lui parle de la relation de l’apprentissage "des bases" dans une équipe de développement pendant un projet.

Pour le détail, je vais commenté ce que j'ai lu :
Citation Envoyé par fatbob Voir le message
Par ailleurs, il faudra m'expliquer comment faire une appli web sans utiliser au moins deux langages (sans compter html et css).
Ce n'est pas ce qu'explique Sam Atkinson, en particulier quand sa conclusion inclus : I think being able to program in multiple languages is an absolute must and is something I look for on a CV."
L'idée du choix de l'apport d'un nouveau langage dans un projet devant suivre cette logique : But you need to be able to properly justify this up front with strong reasoning. The answer shouldn’t be “I fancied trying something new”.

Citation Envoyé par fatbob Voir le message
Quant à l'apprentissage au cours d'un projet... Je ne vois même pas comment on peut faire pour ne pas apprendre à chaque projet.
Chaque développement un peu trapu entraîne des choix et des expériences qui sont des apprentissages. Ceux qui ne fonctionnent pas bien entraineront d'autres choix la fois d'après qui nécessiteront sans doute également une part d'apprentissage.
Le plombier a des normes fixes (relativement) là où un développeur travaille sur des environnements mouvants. Un développement de deux ans et la base de donnée a de nouvelle fonctionnalités, le framework a changé de version majeure, le langage a évolué notablement et le contrat suivant est déjà signé... Où apprend-on dans ce cas ?
Cela soulève deux argument selon moi.
En premier lieu, il faut bien comprendre que l'argument de Yegor Bugayenko est de dire que si tu es sur un projet utilisant le langage X, et que tu es développeur en Y. C'est le manageur qui a fait une boulette et c'est à lui d'assumer la connerie et non à toi : Ask the project manager to fix this.

En second lieu, il ne pas confondre travail et projet. Un emploi ne se résume pas à un ou plusieurs projets. Si tu as un jour un manageur un minimum compétent, tu verra que celui-ci n'affecte pas directement une personne à un projet. En générale, celle-ci a un temps de formation.. En particulier quand une personne rejoins une entreprise.
D'ailleurs, cela est l'une des raisons qui fait qu'un projet ne finit pas "dans les temps", simplement parce que le temps de formation s'est retrouvé dans le temps du projet. Alors, que c'est bien autre chose...
Citation Envoyé par fatbob Voir le message

Au contraire de l'article, je pense que le développeur DOIT se former en permanence, sur tous les projets qu'il fait. Ça fait partie intégrante de son boulot. Celui qui ne le fait pas ne peut pas tenir plus de dix ans avant d'être complètement dépassé sauf à considérer que l'apprentissage des techniques du métier sont un loisir. Je ne vois pas pourquoi un client ou un employeur n'aurait pas à se soucier de cette partie du travail. C'est un peu facile de demander des types de bon niveau, formé aux dernières technologies, sans prendre en compte la nécessité pour ces ressources d'une formation véritablement continue.
Au final, je dirai qu'il faut aussi bien comprendre le degré d'incompétence ciblé est "Je n'ai pas la moindre idée de ce qu'il faut faire." et non "Je ne suis pas sûr d'une chose."
Et encore, encore une fois, ne pas confondre projet, travail et emploie.

Citation Envoyé par dfiad77pro Voir le message
- comment fait-on pour se renouveler si l'entreprise nous cloisonne dans un environnement. ( Je parle pour les dev qui ont des enfants et ne peuvent pas se renouveler chez eux au détriment de l'éducation )
Il y a deux possibilités :
- changer d'entreprise
- Être payer plus et donc avoir la possibilité financier de se re-former

Citation Envoyé par dfiad77pro Voir le message
Bref avec ce genre de considération , beaucoup de DEV quittent la technique pour passer dans le management, c'est une perte considérable !
Beaucoup de "dev" passent dans le management, simplement parce qu'il n'y a pas filière "management technique". La plus part des manageurs actuels sont des anciens développeurs.

Citation Envoyé par LSMetag
Bref, si ce mec là était mon chef de projet, je programmerais toujours en COBOL, parce que ça fonctionne. Quid ensuite de la maintenance et de "l'évolutivité" ? Une fois que tout le monde sera à la retraite, je leur souhaite bien du plaisir.
Vieux ne veux pas dire hors d’usage ou obsolète !
J'ai un ami qui est formateur sur COBOL... IBM maintient un plug-in eclipse pour développer en COBOL. Et oui, c'est pour du bancaire. L'évolutivité, il y a certains moment où tout le monde l'en veux pas. En particulier, quand tu apprends que l'une des versions de PHP avait un problème sur les calculs sur le nombre flottant.
Je ne te reprends pas sur la confusion général que tu réalise entre ton "chef de projet" et ton "supérieur hiérarchique"....
Citation Envoyé par LSMetag
La richesse dans le développement, quand tu y es autorisé, c'est de pouvoir prendre des décisions et faire des propositions pertinentes, en tant que personne sur le terrain, pour le bien-être de l'entreprise et ses clients.
Donc, tu n'as pas pris le temps de lire la source de l'article pour y voir cette partie : But you need to be able to properly justify this up front with strong reasoning. The answer shouldn’t be “I fancied trying something new”.
Ce qui est basiquement ce que tu vient de dire... Visiblement, tu n'es pas une personne sur le terrain en ce qui concerne cette article !

Cordialement,
Patrick Kolodziejczyk.
5  0 
Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 15/04/2015 à 9:54
Citation Envoyé par kdmbella Voir le message
je voudrais bien voir comment un développeur viendra imposer à une entreprise cliente ayant un SI structurer autour d'un langage bien définit, le langage qu'il maîtrise le mieux !
Le problème viens plutôt de la relation client-prestataire d'avant vente.

Si le client dit: "je veux et j'exige que mon application soit fait en Fortran 77", c'est son choix.
Là, le prestataire devra alors trouver une équipe de développement spécialiste en Fortran 77 s'il veut emporter le marché - le client accepte aussi de ne pas avoir trop le choix de l'équipe et donc du prix.

Mais si le client dit "je veux la meilleur solution au moindre coût pour mon application".
Là, le prestataire fera une proposition technologique en fonction des compétences de son équipe disponible afin de rentrer dans le budget du client - et la concurrence peut être plus féroce.

Et puis, il peux y avoir des nuances entre ces deux situations, avec une négociation technologique entre le SI du client et les développeurs.

Mais c'est sur que si les deux, client et prestataire, ne sont pas d'accord sur la technologie choisi, on va au crash.
4  0