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 !

Les étudiants sont-ils assez sensibilisés aux métiers du développement ?
A l'école, la maintenance ne serait pas assez abordée

Le , par mattj

9PARTAGES

13  1 
Il s'agit en fait d'un débât en deux parties.

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

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

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

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

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

Avatar de souviron34
Expert éminent sénior https://www.developpez.com
Le 24/04/2012 à 14:49
Citation Envoyé par LordMacharius Voir le message
Du coup, comment faire pour satisfaire le besoin de formation toujours plus pointu et hétérogène avec des compétences croisées ?
Par justement ne pas enseigner des choses pointues, mais des choses génériques, une manière de penser, d'analyser, un esprit critique, et surtout du bon sens et de la logique...

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

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

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

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

D'où la remarque par rapport au debugger : ne pas savoir se servir de tel ou tel outil, ça s'apprend suivant l'outil... Raisonner pour débugger, c'est de la logique et de l'analyse, quel que soit l'outil (ou sans).
9  1 
Avatar de Hellwing
Membre chevronné https://www.developpez.com
Le 24/04/2012 à 15:33
Parmi toutes ces réponses sur un sujet fort intéressant, je souhaiterai rajouter une petite chose.

Citation Envoyé par grunk Voir le message
Les études d'informatique que j'ai pu faire on pour la plus part du temps été mal adaptée au monde professionnel.

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

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

Après il y'a aussi la réalité du terrain. Les timelines et les directions non technique te force parfois (hélas) à faire un boulot dégueulasse ...
Autant c'est bien connu, les études d'informatique sont en général trop théoriques pour que l'élève soit directement opérationnel à l'entrée sur le marché.

Cependant il ne faut pas oublier que les lacunes viennent également de l'autre côté : les entreprises.
Dans bon nombre d'entre-elles on code à l'arrache pour hier avec comme principal souci la productivité plutôt que le code propre et bien pensé, en ignorant ou en utilisant de travers les outils "théoriques" connus. Certes pour une entreprise la productivité est non négligeable, mais passer du temps sur l'analyse et la conception, le modèle de données, des cycles de développement bien appliqués et un cahier des charges complet et respecté à la lettre n'est jamais du temps perdu. Sauf que ça ne se remarque qu'à plus long terme.

Donc dans l'hypothèse où une entreprise exploite au mieux le modèle de l'ingénierie informatique, non les théories et outils liés indirectement au codage qu'on apprend à l'école est loin d'être inutile.
8  0 
Avatar de CHbox
Membre confirmé https://www.developpez.com
Le 25/04/2012 à 10:08
Je pense aussi que la formation est rarement portée sur la maintenance, on nous apprend à faire du code propre et facile à maintenir (enfin, en théorie), mais on ne nous apprend pas à corriger un code mal conçu, ce qui en fait représente une grosse partie du métier (les raisons ont déjà été cités inutile de paraphraser), on se retrouve souvent à devoir corriger ou modifier le code d'une tierce personne, et ça il faut l'apprendre sur le terrain parce qu'on ne nous y prépare pas

Les cas sont de toute manière trop multiples et trop spécifique pour y être totalement préparé, mais des exercices de "décryptage" de code ne seraient pas de trop, mettre l'élève face à une partie d'un programme (et pas juste 20 lignes, il faut qu'il cherche l’aiguille dans la botte de foin), et lui dire "voilà, le bug c'est ça, ça survient quand je fais ça (et là on est gentils, en cas réel certains utilisateurs décrivent moins que ça....), tu me trouve l'endroit exact où ça foire, et tu proposes 2 solutions, une rapide pour l'urgence, et une permettant d'éviter que ce genre de bug se reproduise".

Mettre face à un cas révoltant (code mal conçu, pas commenté, pas documenté, application qui fait la tartine et le café alors qu'on lui demande beaucoup moins) est le meilleur moyen de faire comprendre l'intérêt des bonnes pratique de développement, et que l'élève se pose les bonnes questions, car on nous dit "il faut toujours bien réfléchir et analyser avant de dev etc..." mais au final, tant qu'on ne voit pas sur quoi ça peut déboucher, on se dit que c'est juste pour faire plus sérieux, alors que non C'EST important de prendre le temps, de commenter, de documenter, de réfléchir avant de se lancer, etc...

De toute manière, on a tous déjà dû faire quelque chose en vitesse et pas le faire au mieux, si ce n'est pas le cas vous avez bien de la chance, mais si vous avez des gens au dessus de vous qui veulent quelque chose, à un moment ou à un autre vous serez amené à faire un truc en vitesse dans l'urgence, et quand on est pas forcément assez expérimenté ça aboutit souvent sur de la casse, et au mieux ça tiendra jusqu'à une demande d'évolution ou il faudra tout refaire, on n'y échappera pas, parfois c'est justifié, parfois c'est juste parce que les entreprises ne pigent pas qu'une appli doit être réfléchi et que ça fait parti du temps de dev.
7  0 
Avatar de souviron34
Expert éminent sénior https://www.developpez.com
Le 26/04/2012 à 10:29
Citation Envoyé par mattj Voir le message
Je pense que cela s'applique parfaitement à notre discussion, même si mon propos n'est pas de chercher à identifier les bons programmeurs (légèrement arrogant quand même)
...
En fait je ne pense pas qu'il faille parler de mauvais développeur mais plutôt de mauvaises pratiques.
En un sens, si...

Bien entendu, les mauvaises pratiques (et les "bonnes" appliquées sans savoir le pourquoi du comment, simplement parce qu'il "faut" le faire)sont un élément...

Bien entendu également la plupart des profs ne sont jamais passs dans la réalité d'un gros dev d'un gros projet au sein d'une grosse équipe, et n'ont le plus souvent que des connaissance théoriques..

Mais aussi, le phénomène est non-négligeable, que ce soit l'engouement (personnel, via jeux et "passion" de jeune, ou de la société en général pour le domaine), que ce soit l'incompétence des recruteurs (qui ne savent la plupart du temps du temps de quoi ils parlent et se font avoir par les derniers buzz-words marketing), que ce soit le règne de l'enfant-roi qui fait dre aux parents "mon gosse est un petit génie", que ce soit enfin les formations qui prônent que l'informatique est un domaine d'avenir, sans préciser que c'est un domaine de création et intellectuel, tout cela crée des "mauvais" programmeurs, dans le sens où ils savent coder en utilisant ce qu'on a leur donné, mais ce ne sont pas des "intellectuels" et des "créateurs"... On les forme pour être des "ouvriers à la chaîne", avec l'illusion qu'ils sont des bons, et des créatifs...

Or le métier est basé là-dessus...

La formation et le développement "de masse" du métier fait que forcément la proportion de "mauvais" dans ce sens-là, c'est à dire simplement de personnes qui n'ont pas forcément les outils/bagages pour effectuer un travail de création intelligemment, augmente..

Et, comme je disais, cette illusion est propagée par la formation et l'enseignement... (ne serait-ce que les formations pour avoir un diplôme de CP )

L'illusion rousseauiste que "l'homme est bon" s'est propagée depuis le milieu des années 80 comme étant "tout le monde peut être intellectuel et créatif"...

Ce qui est bien évidemment faux..

Il y a donc effectivement des "bons" et des "mauvais", comme partout.. L'informatique n'est pas un domaine à part... où il n'y aurait que des "bons".. dont certains ne seraient pas découverts...
7  0 
Avatar de sevyc64
Modérateur https://www.developpez.com
Le 30/04/2012 à 10:35
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.
6  0 
Avatar de Mr_Exal
Membre expert https://www.developpez.com
Le 25/04/2012 à 11:28
Citation Envoyé par Cyrilange Voir le message
Je vais même plus loin en disant que la vie d'un logiciel ne doit pas dépasser 5 ans.

LA phrase à retenir pour le développement : "Tant que ça fonctionne, on n'y touche pas."

A quoi bon vouloir refaire un programme avec une technologie x ou y tant qu'il tourne comme il faut (donc dépenser inutilement de l'argent et des ressources humaines) et qu'il n'a presque pas (parce qu'aucun est impossible) de bug(s) ?
5  0 
Avatar de sevyc64
Modérateur https://www.developpez.com
Le 22/04/2012 à 21:11
Pour la première partie, tout dépend du poste occupé. Pour ceux qui travaillent essentiellement au projet ponctuel (même s'il est long), ils ne feront probablement que peu de maintenance.
Ceux, par contre travaillant sur de la plus longue durée, faisant carrière dans une même entreprise par exemple, ou autre, feront effectivement beaucoup de maintenance de l'existant. Si le rapport 90/10 semble correspondre au cas particulier de l'auteur cité, à bien analyser les choses, la part de maintenance est très probablement majoritaire, oui!

Pour la seconde partie, je n'ai pas fait d'école d'informatique donc je ne sais pas précisément ce qui s'y enseigne, mais j'en ai malgré tout une bonne vision par l'intermédiaire notamment des jeunes diplômés que j'ai eu l'occasion de côtoyer.
Il me semble qu'il leur ait plus enseigner tout ce qui est analyse, conception, gestion de projet, etc.
Par contre, ils ont généralement de grosses lacunes dans tout ce qui est codage, que ce soit les bonnes règles, l'organisation du code, la maintenabilité donc, mais aussi la traduction des études de conception en code qui fonctionne.
Autre grosse lacune, et très grosse celle-là, c'est que quasiment aucun des jeunes diplômes que j'ai pu côtoyer jusqu'à maintenant ne sais vraiment debugger et tester un logiciel. C'est effarant, d'entendre te dire par de jeunes ingénieurs qui prétendent avoir 5 à 7 ans d'informatique ne pas savoir ce qu'est un point d’arrêt, à quoi ça sert et comment s'en servir.
4  0 
Avatar de souviron34
Expert éminent sénior https://www.developpez.com
Le 24/04/2012 à 11:14
Citation Envoyé par mattj Voir le message
Pensez-vous que l'essentiel du métier de développeur consiste à maintenir des logiciels existants?
Citation Envoyé par sevyc64 Voir le message
Pour la première partie, tout dépend du poste occupé. Pour ceux qui travaillent essentiellement au projet ponctuel (même s'il est long), ils ne feront probablement que peu de maintenance.
Ceux, par contre travaillant sur de la plus longue durée, faisant carrière dans une même entreprise par exemple, ou autre, feront effectivement beaucoup de maintenance de l'existant. Si le rapport 90/10 semble correspondre au cas particulier de l'auteur cité, à bien analyser les choses, la part de maintenance est très probablement majoritaire, oui!
@sevyc64 : Je ne suis pas d'accord avec ta "séparation", très française.. Ce n'est pas parce qu'on reste longtemps dans la même boîte que l'on fait plus de maintenance..

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

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

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

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

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

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

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

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

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


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

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

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

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

Citation Envoyé par mattj Voir le message
Pensez-vous que les universités, les écoles françaises, préparent correctement les étudiants aux métiers du développement logiciel?
Citation Envoyé par sevyc64 Voir le message
Par contre, ils ont généralement de grosses lacunes dans tout ce qui est codage, que ce soit les bonnes règles, l'organisation du code, la maintenabilité donc, mais aussi la traduction des études de conception en code qui fonctionne.
Autre grosse lacune, et très grosse celle-là, c'est que quasiment aucun des jeunes diplômes que j'ai pu côtoyer jusqu'à maintenant ne sais vraiment debugger et tester un logiciel. C'est effarant, d'entendre te dire par de jeunes ingénieurs qui prétendent avoir 5 à 7 ans d'informatique ne pas savoir ce qu'est un point d’arrêt, à quoi ça sert et comment s'en servir.
Je ne travaille que peu avec des jeunes, mais il suffit de voir ici, que ce soit sur les forums techniques ou sur ce forum, à propos des debuggers et autres, ou de la lisibilité du code..

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

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

Citation Envoyé par mattj Voir le message
Personnellement je n'ai jamais vu de carte perforée pour de vrai
Moi si Le sujet de thèse d'une de mes collègues à l'époque était la traduction d'un programme scientifique de cartes perforées en programme "fichier".. Et c'était en 1982 ...
5  1 
Avatar de
https://www.developpez.com
Le 24/04/2012 à 16:45
Citation Envoyé par mattj Voir le message
pensez-vous que l'essentiel du métier de développeur consiste à maintenir des logiciels existants ?
Oui... M'enfin en grande partie. Sur mes 2 ans et demi d'XP , j'ai effectué 5 missions. Une seule d'entre elles portait sur une application à développer from scractch à partir de zéro. Les 4 autres c'était de la maintenance. Perso je n'ai pas de problème parce que par définition un logiciel n'est pas fini. il y aura tôt ou tard :
  • une petite fonctionnalité qui manque, qu'on n'aurait pas pris en compte dès le départ et qu'il faudra ajouter : il s'agit d'une maintenance évolutive.
  • Des bugs qui ont échappé lors des phases de test du logiciel et qu'on a détectés grâce à l'un des cas d'utilisation un peu tordue d'un utilisateur ou tout simplement que la montée en charge du logiciel a entraîné de gros problème de performance : il s'agit d'une maintenance corrective.

Perso, je n'ai aucun problème à effectuer l'un ou l'autre des 2 types de maintenance (bien que je préfère une évolution qu'une correction de bugs). Je considère cela comme un challenge à relever et après tout on saura comment c'est fait ailleurs. Si c'est mal fait on prend note pour ne pas faire la même bêtise que les développeurs qui ont développé la première version du logiciel. Si c'est bien fait alors alors tant mieux il y aura moins de stress et avec un peu de chance on aura découvert comment une architecture qu'on ne maîtrisait pas a été mise en place et du coup on se met à jour au niveau connaissance.

Le problème n'est pas le fait qu'on fasse beaucoup de maintenance. Pour moi le véritable problème c'est la qualité de certaines applications. Sur les 4 applications pour lesquelles j'ai fait la maintenance un seul respectait une architecture bien définie avec une très bonne documentation technique. Le reste c'était du n'importe quoi et il fallait de la gymnastique partout dans le code pour pouvoir ajouter la nouvelle fonctionnalité demandée. Le truc le plus gênant ce sont les effets de bords qui me font perdre un temps énorme parce que tout simplement t'as modifié un truc et un autre truc qui marchait avant ne marche plus.
Bref je ne regrette pas du tout d'avoir commencé par la maintenance parce j'apprend plein de chose comme ça et cela évite que je fasse les bêtises que j'ai rencontrées dans une nouvelle application.

Citation Envoyé par mattj Voir le message
Pensez-vous que les universités, les écoles françaises, préparent correctement les étudiants aux métiers du développement logiciel ?
Je connais pas trop l'enseignement en France, mais apparemement dans les écoles, les élèves sont préparés à être chef de projet. Donc à un seul métier. Au Sénégal par contre j'avais un professeur qui nous faisait ses retours d'expérience dans les différents entreprises où il a travaillé, nous parlait des bonnes pratiques etc...

Citation Envoyé par mattj Voir le message
Devrait-on avoir un cours de maintenance où l'on donnerait comme projet annuel un sujet du genre "Rajouter telle ou telle fonctionnalité" à un projet mal "designé" ?
Ce serait intéressant d'avoir un projet de ce type. Dans ce cas, je préfère plutôt que le projet parte d'une application sans architecture codée par le professeur lui-même en y insérant tous les anti-patterns connus. Après dire aux étudiants de les détecter et de les corriger. Voilà c'est ça la réalité sur le terrain. La plupart des applications mal faites sont sûrement codées par des débutants. Connaitre les bonnes pratiques en partant d'une application pourrie est une bonne idée
4  0 
Avatar de mattj
Membre habitué https://www.developpez.com
Le 25/04/2012 à 23:39
Tout d'abord je précise que j'appelle dans ce message "maintenance" le fait de modifier le code d'une application après release, afin de corriger des bugs et de modifier ou ajouter des fonctionnalités.

Citation Envoyé par arkhamon Voir le message
Et pour les bugs, je vais être un peu méchant, mais quand un code est conçu dans les règles de l'art (encapsulation, séparation des codes, unicité de fonction, visibilité des infos...), ben normalement il ne devrait plus rester que les erreurs de conception. Et si les phases de tests sont conduites avec diligence, sincérité et professionnalisme, ben devrait plus y avoir de bugs du tout.
C'est justement l'enjeu de cette discussion! En fait pour moi il y a deux aspects dans ce que j'appellerais 'l'enseignement de la maintenabilité":
  • maintenir du code existant
    J'aime en particulier l'idée de h2s84 :
    Citation Envoyé par h2s84 Voir le message
    Dans ce cas, je préfère plutôt que le projet parte d'une application sans architecture codée par le professeur lui-même en y insérant tous les anti-patterns connus. Après dire aux étudiants de les détecter et de les corriger. Voilà c'est ça la réalité sur le terrain. La plupart des applications mal faites sont sûrement codées par des débutants. Connaitre les bonnes pratiques en partant d'une application pourrie est une bonne idée
  • créer du code maintenable
    L'aspect principal à mon avis : dès qu'un projet est mis en production il passe par définition dans la catégorie des projets en maintenance (vlegaci.com, cité plus haut, semble du même avis). La plupart des projets "réussis" passent donc plus de temps en maintenance qu'en développement. C'est pourtant la phase de développement qui conditionne la complexité de la phase de maintenance, et donc le coût final.
    Dans une assez célèbre interview de David Parnas, celui-ci déclare:

    Q What is the most often-overlooked risk in software engineering?
    R Incompetent programmers. There are estimates that the number of programmers needed in the U.S. exceeds 200,000. This is entirely misleading. It is not a quantity problem; we have a quality problem. One bad programmer can easily create two new jobs a year. Hiring more bad programmers will just increase our perceived need for them. If we had more good programmers, and could easily identify them, we would need fewer, not more.
    Je pense que cela s'applique parfaitement à notre discussion, même si mon propos n'est pas de chercher à identifier les bons programmeurs (légèrement arrogant quand même), mais plutôt de mettre en évidence des lacunes dans les formations, en particulier sur le plan de la maintenabilité du code. Je ne sais pas si un mauvais développeur peut vraiment créer deux emplois, mais il peut coûter extrêmement cher en temps et en argent. En fait je ne pense pas qu'il faille parler de mauvais développeur mais plutôt de mauvaises pratiques. Un bon développeur, à la réflexion et l'analyse aiguisés, capable de se former rapidement à n'importe quelle technologie, ayant le souci du détail, etc., mais appliquant de mauvaises méthodes produira un code difficile à maintenir comme tout le monde...d'où le problème.


Il y a déjà eu quelques éléments de réponse, mais pensez-vous que le problème soit franco-français?
4  0