Discussion :

[Christian Olivier]

Les développeurs consacrent trop de temps à corriger le mauvais code
Au lieu de se focaliser sur de nouveaux projets, ce qui pénalise les entreprises

À mesure que la technologie se dilue dans tous les aspects de l’économie mondiale, les ingénieurs informatiques en génie logiciel apparaissent de plus en plus comme l’une de leurs ressources les plus précieuses.

Une étude publiée récemment par Stripe, l’éditeur d’une plateforme et d’applications de paiement en ligne, semble valider l’hypothèse selon laquelle l’allocation d’une trop grande quantité de temps à la maintenance plutôt qu’au développement de nouveaux projets peut avoir un impact économique non négligeable sur une organisation.

L’enquête a été menée pour Stripe par l’institut Harris Poll. Plus de 2000 développeurs, responsables techniques et des cadres supérieurs de niveau C à travers six pays (incluant la France, l’Allemagne, le Royaume-Uni, Singapour et les États-Unis) ont été interrogés. Elle présente les développeurs comme un facteur qui reste encore trop négligé, alors qu’il peut avoir un impact décisif pour le succès futur d’une entreprise (production, vente, différentiation, visibilité, etc.). Cette étude fournit également un aperçu de la vision des décideurs dans le milieu entrepreneurial.

Une très grande partie des cadres supérieurs sondés estiment que leurs entreprises aujourd’hui sont confrontées à des défis qui vont bien au-delà de leur simple objectif de rentabilité. Ces challenges sont essentiellement d’ordre sécuritaire (66 %) et règlementaire (62 %), concurrentiel (60 %) ou liés à la disponibilité d’une main-d’œuvre de qualité (61 %). ils sont plus préoccupés par les questions ayant trait à l’accès à l’information et à la technologie que des problèmes liés à l’immigration et à l’accès au capital ou aux marchés.

La majeure partie des cadres supérieurs (44 %) estiment que leurs concurrents de l’industrie de la technologie représentent la plus grande menace pour leurs activités. C’est pour cette raison qu’ils envisagent de prioriser les investissements sur l’infrastructure logicielle (41 %), la R&D (31 %) et le recrutement (31 %) au cours des cinq prochaines années.

Les développeurs et les exécutifs de niveau C s’accordent à dire que l’intelligence artificielle (IA), les services basés sur les API et l’Internet des Objets (IoT) représentent les tendances technologiques qui actuellement impactent le plus fortement sur leurs activités. Le Machine Learning (ML), les assistants virtuels et la Blockchain devraient compléter cette liste dans les dix prochaines années.

Les cadres supérieurs sont un peu plus optimistes que les développeurs lorsqu’on leur demande s’ils pensent que leurs entreprises disposeront de ressources suffisantes pour tirer parti de ces tendances technologiques (83 % contre 77 %). Les développeurs qui ne partagent pas ce point de vue optimiste justifient leurs inquiétudes par le fait que leurs entreprises sont trop lentes à régir, ne disposent pas de suffisamment d’employés qualifiés ou des infrastructures techniques adéquates, mais aussi par le fait que les dirigeants de leurs entreprises n’accordent pas suffisamment de priorité à la technologie.

Bien qu’il soit prioritaire pour les cadres supérieurs d’accroitre la productivité de leurs développeurs (96 % l’ont signalé), cette étude montre que chaque développeur consacrerait en moyenne plus de 17 heures par semaine (jusqu’à 20,9 heures en France) à la maintenance : débogage, refactoring, etc. Chaque développeur passerait près de 4 heures à retoucher du « mauvais code », plutôt que de s’investir dans de nouveaux projets.

Six développeurs sur dix jugent eux-mêmes « excessif » le temps dédié au « mauvais code ». Pour les entreprises qui les emploient, ce qui à l’échelle mondiale équivaudrait chaque année à un manque à gagner d’environ 85 milliards USD en termes de « cout d'opportunité ».

Les développeurs (18 millions dans le monde) peuvent agir ensemble comme un « multiplicateur de force » puisque, comme l’a précisé l’enquête, ils « ont le potentiel, collectivement, d’augmenter le PIB mondial de 3000 milliards de dollars au cours des dix prochaines années ». Les organisations qui les emploient auraient donc tout intérêt à les « utiliser » plus efficacement.

Source : Stripe (PDF)

Et vous ?

Que pensez-vous des données exposées dans cette étude ?

Voir aussi

Emploi développeur 2017 : les langages les plus demandés et les mieux payés, Java, JavaScript et PHP plus demandés, mais Perl, Go et Scala mieux payés
France : en 2017, 32 % des logiciels installés en entreprise ne disposaient pas d'une licence conforme, d'après une étude de la BSA
Avez-vous déjà travaillé avec un développeur qui se sert de méthodes frauduleuses ? Partagez votre expérience
Trolldi : à partir de quel âge est-il raisonnable pour un développeur de s'orienter ailleurs ?

[sebastiano]

Les décideurs dans les entreprises n'ont pas toujours conscience qu'une bonne équipe d'ingénieurs va conduire au succès. De plus, beaucoup de ces sociétés sont parasitées par des éléments qui ne produisent rien. Ou trop peu par rapport au salaire engrangé (et je ne parle pas que des autres métiers, j'ai connu des dévs web à 70k brut incapables de créer une vue).

[CaptainDangeax]

Ma mission actuelle arrive à son terme, le projet est bouclé et fonctionnel. Je n'ai pas eu à toucher au code powershell de mon prédécesseur, à part pour rajouter un cas de configuration non prévu au départ. Par contre, j'ai ré-écrit 80% de ce qu'il avait écrit en bash...

Les décideurs dans les entreprises n'ont pas toujours conscience qu'une bonne équipe d'ingénieurs va conduire au succès. De plus, beaucoup de ces sociétés sont parasitées par des éléments qui ne produisent rien. Ou trop peu par rapport au salaire engrangé (et je ne parle pas que des autres métiers, j'ai connu des dévs web à 70k brut incapables de créer une vue).

De mon coté, j'ai connu des ingé système qui étaient des quiches en BDD, donc complètement paumés dès que les données sont stockées dans un SQLITE ou autre ; inutile de leur demander un rapport.
Il y a aussi les chefs de projet slideware (spécialistes powerpoint, pauvre point en français), qui ne savent pas identifier un chemin critique et pour qui une socket réseau c'est du babylonien.
Enfin, il y a les pipeauteurs de CV, qui se font repérer rapidement, comme un ingénieur système windows qui ne savait pas importer un fichier texte dans excel.

[el_slapper]

(.../...) (et je ne parle pas que des autres métiers, j'ai connu des dévs web à 70k brut incapables de créer une vue).

Vu aussi. Enfin, pas en web, c'est pas mon domaine, mais vu.

Le souci à mon sens vient de plus loin. On a des besoins énormes en terme de production de code. Jusque là, je pense ne surprendre personne. Donc on forme plus de gens. Mais il y a une incompréhension fondamentale du marché sur ce qu'est un programmeur(c'est sans doute vrai aussi dans d'autres domaines, mais pour le coup, j'assume ma propre incompréhension des autres domaines). Dans l'esprit des non-programmeurs, c'est juste un technicien, qui apprend une technique, et qui l'applique. D'ou le matching massif des recruteurs/commerciaux sur les mots-clefs, d'ailleurs.

En fait, non. Un programmeur, c'est (1)quelqu'un qui est capable de concevoir une méthode aussi élégante, courte, et efficace que possible pour permettre à la machine de prendre une série de décisions pertinentes, telles qu'attendues par les utilisateurs. C'est donc quelqu'un qui a besoin d'une certaine culture intellectuelle(d'ou les forums comme DVP ou on débat de la pertinence des getters/setters par rapport aux propriétés/méthodes, et de ce que ces termes doivent recouvrir). C'est (2)quelqu'un qui a besoin d'être capable de réfléchir à plusieurs niveau d'abstraction simultanément(une qualité qui me semble innée. Je peux avoir tort, mais je n'ai jamais vu quelqu'un l'acquérir). C'est (3)quelqu'un capable de soumettre son esprit à l'idée que la machine n'infère rien, que la machine n'est pas un humain, et que si la machine répond mal, c'est de la faute à la question. Toujours.

Mais au lieu de filtrer sur le point 2, et de donner une éducation complète sur les points 1 et 3, on se focalise sur des détails techniques. Et on fait apprendre aux gens les design patterns par cœur, au lieu de leur faire découvrir pourquoi(et dans quelles circonstances) ils sont pertinents. Et on filtre sur les maths, qui ne sont pas un filtre optimal, restons polis. Ce qui nous fait parfois des gens qui n'ont pas la bonne tournure d'esprit, et souvent pas la formation intellectuelle pour rentrer dans le dur. Et en plus, on forme en masse. Dans un domaine ou la qualité est primordiale, on privilégie la quantité. Et mal ciblée, en plus. A laquelle on rajoute le jeunisme qui nous prive de ressources sénior qui feraient tellement de bien.

Et on se retrouve avec ton dev web, qui a un niveau de maths honnête, qui connait plus ou moins ses outils techniques, mais est incapable de faire une vue(je ne sais pas ce que c'est, je ne connais rien au web), c'est probablement quelqu'un qui est bloqué sur des points que j'ai cité. Peut-être même les trois. Et il laisse derrière lui tout ce mauvais code qui nécessite tant de temps à nettoyer(pour retourner au sujet initial).

[Edrixal]

Que c'est plutôt représentatif du monde dans lequel nous vivons. Les gens pense avoir la science infuse, les gens n'arrive pas à comprendre qu'une personne ne puisse pas avoir les mêmes connaissance qu'eux, les gens n'arrive pas à accepté que l'on puisse penser et faire différemment d'eux (sans pour autant être dans le faux), ect...

Il suffit de voir les réactions apporter ici pour comprendre que les dev semble plus s'attarder sur des détails comme "Les commentaires sont écrit en Français !" ou "Franchement j'aurais pas fait comme ça, là c'est n'imp" plutôt que d'essayer de comprendre la logique du code, le pourquoi il à été développer ainsi, de comprendre que les personnes qui on développer dessus n'avais probablement pas le temps de reprendre le projet, que le projet est vieux et qu'il est passer entre plusieurs main, ect...

En fait je pense qu'a force de vouloir prouver que l'on est toujours meilleurs que son voisin quitte à lui écraser la gueule pour rien, c'est le mot d'ordre. Ainsi plutôt que d'aider son collègue à développer ses compétences on lui écrase la tête dans son caca en lui disant "t'es nul !".

[sebastiano]

Il suffit de voir les réactions apporter ici pour comprendre que les dev semble plus s'attarder sur des détails comme "Les commentaires sont écrit en Français !" ou "Franchement j'aurais pas fait comme ça, là c'est n'imp" plutôt que d'essayer de comprendre la logique du code, le pourquoi il à été développer ainsi, de comprendre que les personnes qui on développer dessus n'avais probablement pas le temps de reprendre le projet, que le projet est vieux et qu'il est passer entre plusieurs main, ect...

C'est loin d'être l'apanage des devs.

Des réunions retardées, reportées ou dénoncées pour 1 faute d'orthographe dans un doc technique, ou un client qui refuse une présentation faite par un interlocuteur maîtrisant le Français mais ayant un très léger accent, ou encore des prises de tête violentes parce que la patron du pôle dev a osé mettre un cheveux dans le périmètre du pôle intégration pour faire avancer le projet.

Au-delà des détails, c'est plutôt un trait très français dans les entreprises, que de pointer des responsabilités ou des détails plutôt que d'agir pour le bon déroulé du projet. Et ce, à tous les niveaux.

[sirthie]

C'est loin d'être l'apanage des devs.

Des réunions retardées, reportées ou dénoncées pour 1 faute d'orthographe dans un doc technique, ou un client qui refuse une présentation faite par un interlocuteur maîtrisant le Français mais ayant un très léger accent, ou encore des prises de tête violentes parce que la patron du pôle dev a osé mettre un cheveux dans le périmètre du pôle intégration pour faire avancer le projet.

Au-delà des détails, c'est plutôt un trait très français dans les entreprises, que de pointer des responsabilités ou des détails plutôt que d'agir pour le bon déroulé du projet. Et ce, à tous les niveaux.

Parce que tu compares du mauvais code à "1 faute d'orthographe dans un doc technique" ? Quand j'ai du refaire des pages web, j'ai dû les refaire from scratch tellement le code était pléthorique, obsolète, redondant, etc., etc.

Optimiser le code FAIT PARTIE (ou devrait faire partie) du "bon déroulé du projet. Et ce, à tous les niveaux". Pas pour faire chier les gens, mais parce que sur la durée, c'est une nécessité. En tout cas dans le web.

[sebastiano]

Donc, on en revient que là, on ne corrige pas, on fait évoluer en modifiant le code voir le remplacer totalement à cause de la nouvelle définition du besoin.

Qu'appelle-t-on un mauvais code:

• Un code obsolète vis à vis des évolutions de besoin ?
• Un code fait avec les pieds (mais qui réponds au besoin) ?
• Autre ?

Selon la définition que l'on se fera de "mauvais code", l'étude aura une tout autre connotation...

Enfin, c'est mon avis.

Ca c'est de l'interprétation. Un code qui a été réclamé pour répondre en franc et qui répond en franc, on ne peut pas le taxer de mauvais code parce qu'il n'a pas prévu de répondre en Euro. Ce n'est qu'un souci en amont. Ce n'est pas du ressort du développeur.

Parce que tu compares du mauvais code à "1 faute d'orthographe dans un doc technique" ? Quand j'ai du refaire des pages web, j'ai dû les refaire from scratch tellement le code était pléthorique, obsolète, redondant, etc., etc.

Optimiser le code FAIT PARTIE (ou devrait faire partie) du "bon déroulé du projet. Et ce, à tous les niveaux". Pas pour faire chier les gens, mais parce que sur la durée, c'est une nécessité. En tout cas dans le web.

Reprenez mon message, en respirant bien, et vous en comprendrez le sens. Un indice se cache dans sa première phrase.

[disedorgue]

Ca c'est de l'interprétation. Un code qui a été réclamé pour répondre en franc et qui répond en franc, on ne peut pas le taxer de mauvais code parce qu'il n'a pas prévu de répondre en Euro. Ce n'est qu'un souci en amont. Ce n'est pas du ressort du développeur.

En fait, on est d'accord depuis le début, ce code (qui n'est pas un mauvais code) ne fait pas partie du sujet de l'étude ?

[sirthie]

Reprenez mon message, en respirant bien, et vous en comprendrez le sens. Un indice se cache dans sa première phrase.

J'ai lu et relu la première phrase de votre message ("C'est loin d'être l'apanage des devs.") et tout le reste de celui-ci en frôlant l'hyperventilation.

Je dois donc être totalement crétin.

Je ne nie absolument pas que les comportements que vous citez existent, et c'est évidemment déplorable. Simplement, vous comparez des petits pois avec des citrouilles. De par mon expérience (intégration web), le mauvais code est un problème grave et n'a rien à voir avec des comportements vexatoires pour cause de faute d’orthographe inaperçue ou d'accent d'un intervenant.

[kilroyFR]

Chez nous la maladie de pas mal de devs c'est de reinventer la roue ... carrée.
En 2018, pour des applis de gestion, je ne comprends pas qu'on reinvente des frameworks maison, alors que bien souvent notre metier (sur la partie technique) devrait se limiter a faire de l'assemblage de composants existants (hors code purement logique metier bien sur).
On ne cherche pas a voir ce qui existe deja et qui pourrait faire le boulot, on reecrit (avec les bugs bien sur).
Ca c'est vraiment du temps perdu. De plus certains ont l'art de complexifier l'archi des logiciels (c'est surement pour donner du credit a ce qu'ils font).
Personnellement la maintenance est simplifiée et peu couteuse des lors que la conception est simple et modulaire.
Ca permet de resoudre efficacement n'importe quel probleme. Je dis toujours, si c'est complexe a coder c'est que la conception est mal foutue. Ca s'est toujours verifié en pratique sur tous les projets sur lesquels j'ai travaillé.
Je prefere largement une bonne conception simple et des devs moyens que des conceptions complexes (a cout de multiplication de technos et autres mille feuilles logiciel) et des 'ninja du code' (qui satisfont leur ego mais rendent le code inmaintenable par quiconque).
Surtout qu'un prestataire peut se faire plaisir (on a vecu le cas au moins 2 fois et ca nous a couté enormement en maintenance), il s'en fout il n'assurera pas la maintenance sur le moyen/long terme mais ceux qui doivent recuperer/gerer le(s) appli(s) et c'est souvent là le drame (de mon experience). Repasser derriere des devs qu'on a laissé s'amuser avec les technos (pas toujours justifié) c'est catastrophique pour la maintenance par la suite.

[mister3957]

Il ne faut pas confondre complexe et compliqué.

On répond à des problématiques complexes qui nécessitent forcément des réponses complexes, sinon pas besoin de nous, autant le faire à la main.

Par contre, sauf dans de rares cas, ce n'est pas normal en 2018 que ça vire au compliqué. Sinon effectivement ça pue le mauvais choix, d'outils et/ou de conception et/ou de personne, en tout cas il y a un loup en amont quelque part effectivement.

Cette complexité elle doit rester métier / orga / management / moyens / temps etc. Lorsque ça vire à la technique ça pue le geek qui s'est encore embarqué dans des trucs et des machins pensant tout faire tout mieux que tout le monde et surtout de ce qu'il ne connait pas.

J'ai trouvé deux phénomènes provocateurs :
- Les "chefs" ou "décideurs" ou "mecs du conseil" qui veulent une proportionnalité entre coder et produire. Donc 0 place à la sensibilité, formation, la veille, etc.
- Les geeks suprêmes maîtres du monde. Donc 0 place à la sensibilité, la formation, la veille, etc.

Et lorsque le chef est geek, meilleur amis de ses devs geek, là ça schlingue du cul sévère ^^

[Pyramidev]

Il suffit de voir les réactions apporter ici pour comprendre que les dev semble plus s'attarder sur des détails comme "Les commentaires sont écrit en Français !" ou "Franchement j'aurais pas fait comme ça, là c'est n'imp" plutôt que d'essayer de comprendre la logique du code, le pourquoi il à été développer ainsi, de comprendre que les personnes qui on développer dessus n'avais probablement pas le temps de reprendre le projet, que le projet est vieux et qu'il est passer entre plusieurs main, ect...

En fait je pense qu'a force de vouloir prouver que l'on est toujours meilleurs que son voisin quitte à lui écraser la gueule pour rien, c'est le mot d'ordre. Ainsi plutôt que d'aider son collègue à développer ses compétences on lui écrase la tête dans son caca en lui disant "t'es nul !".

Pour la partie « Franchement j'aurais pas fait comme ça, là c'est n'imp », je fais probablement partie des gens visés, car j'ai critiqué le nommage des variables ici et certains amas de valeurs en dur dans le code là. Donc j'ai critiqué le code, mais à aucun moment dans le fil je n'ai affirmé que les développeurs qui avaient écrit ce code étaient nuls. Je sais que, s'il n'y a pas eu assez de temps consacré au réusinage de code, ce n'est pas forcément la faute des développeurs.

Dans mon premier message, j'avais réagi à ta phrase « Dans l'ensemble d'un avis personnel, je trouve le code clair et lisible. »

[Edrixal]

je fais probablement partie des gens visés,

Je rebondi juste sur cette phrase pour dire que je ne cité personne personnellement et que je n'ai pris cette discutions en exemple que parce qu'il était plus simple d'expliquer mon point de vue ainsi que de faire une longue logorrhée sur les prises de tête que j'ai pu avoir avec certaine personne dans la vie qui par exemple, me prenais la tête parce que mes dev (nom de variable/fonction, commentaire, message d'erreur, ect...) sont en Français et non en Anglais.

Donc, la question déjà à se poser est de déterminer ce que l'on appelle du mauvais code ?

D'un avis personnel toujours, un mauvais code est un code qui ne fait pas ce qu'il devrait faire (bug, oublie de certain module ect...). Sinon, même si le code est fait n'importe comment, mais que le résultat est là, le code fonctionne, il n'est donc pas mauvais.

Je mettrait tout de même un bémol sur les personnes qui écrivent volontairement leur code n'importe comment pour être les seuls à pouvoirs les maintenir et les faire évoluer correctement et facilement. Quoi qu'a ce niveau là ce serait plutôt le dev qui serait mauvais que son code finalement

[sirthie]

D'un avis personnel toujours, un mauvais code est un code qui ne fait pas ce qu'il devrait faire (bug, oublie de certain module ect...). Sinon, même si le code est fait n'importe comment, mais que le résultat est là, le code fonctionne, il n'est donc pas mauvais.

Je ne voudrais pas être désobligeant, mais à te lire, j'ai l'impression que tu n'as jamais codé. Il y a plein de codes qui "fonctionnent"... jusqu'à ce que tu modifies quelque chose, et là, c'est le bordel, et tu sais même pas déterminer pourquoi, tellement le code est un foutoir pas possible.

Donc, non, un bon code n'est pas seulement un code qui "fonctionne" (dans un état donné) ; ça, c'est pour les utilisateurs.

Un bon code doit également être un code bien organisé, bien structuré, bien commenté, optimisé, factorisé, minimal, lisible, intelligible, avec des conventions de nommage, conforme aux standards/pratiques actuell(e)s, etc., etc.

De mon point de vue, des codes absolument surdimensionnés, comme un jQuery pour réaliser des effets qui peuvent être obtenus avec quelques lignes de CSS, ou un Bootstrap pour réaliser un site one page, c'est aussi du mauvais code (les noms des classes CSS de Bootstrap sont très peu explicites).

Je mettrait tout de même un bémol sur les personnes qui écrivent volontairement leur code n'importe comment pour être les seuls à pouvoirs les maintenir et les faire évoluer correctement et facilement. Quoi qu'a ce niveau là ce serait plutôt le dev qui serait mauvais que son code finalement

Je ne nie pas que cela puisse exister, mais avec mon expérience (intégrateur web), j'ai beaucoup de mal à imaginer la chose. Faire ça volontairement serait tout simplement vraiment trop contraignant pour le codeur.

De surcroît, s'il postule pour un nouvel emploi quel code pourrait montrer à un employeur un codeur tel que vous l'évoquez ? Et n'oubliez pas que dans le web, on peut consulter le code...

Enfin, dans le web, toujours, on travaille souvent en équipe. J'ai du mal à imaginer que quelqu'un qui fait du mauvais code (au moins) volontairement ne se fasse pas repérer tôt ou tard à tout le moins s'il n'est pas seul dans son domaine (front-end, back-end) à travailler dans la boite.

[el_slapper]

(.../...).

+1, et je vais troller pour en rajouter un peu : un code qui marche, c'est 50% du boulot, à peine.

[Edrixal]

Je ne voudrais pas être désobligeant, mais à te lire, j'ai l'impression que tu n'as jamais codé. Il y a plein de codes qui "fonctionnent"... jusqu'à ce que tu modifies quelque chose, et là, c'est le bordel, et tu sais même pas déterminer pourquoi, tellement le code est un foutoir pas possible.

Je ne code que depuis quelques année certes, mais je touche quotidiennement à différents langages sur différent logiciel qui ont tous été développer par une ou plusieurs personnes différentes au cours de ses 15/20 dernières années. Alors du code qui claque au moindre changement je connais. En fait sur certain logiciel j'ai pris la décision de ne jamais toucher l'existant mais d'ajouter une couche, c'est chiant, souvent compliquer, je râle beaucoup mais ça tient et fonctionne. Et quand je ne peu pas faire autrement, je prend le temps de commenter un maximum (ouai parce que les mecs qui développe et qui commente sont rare...) ce que j'arrive à comprendre pour pouvoir m'y retrouver plus tard.

Bref, ses codes en bordel, très difficilement évaluable... Bha c'est mon quotidien. Est ce du mauvais code pour autant ? Va savoir, est ce que les personnes qui ont coder ça on mis en place le logiciel sur un coup de chance ? Est ce que ce ne sont pas les différentes personnes qui sont passer les unes à la suites des autres qui rendent le code aussi difficile ? Les couches que j'ai ajouter ne sont pas forcément plus propres que ce qui existe déjà. Au moins elles sont commentées...

Le code n'est pas propre c'est clair. J'aurais bien envie de tout ré-écrire, mais honnêtement même les clients n'ont pas toute les spec de leur produit... Alors tout refaire en ce basant uniquement sur un code très peu lisible c'est surtout prendre le risque d'oublier quelques chose. Ou de ce rendre compte trop tard qu'on à pas vue telle ou telle fonctionnalité très spécifique. Et là deux solution, tout ré-écrire une nouvelle fois ou l'ajouter à l'arrache. En bref, c'est faisable, mais il faut avoir beaucoup de temps à perdre alors que le code actuel fonctionne et fait le taff.

Donc, non, un bon code n'est pas seulement un code qui "fonctionne" (dans un état donné) ; ça, c'est pour les utilisateurs.

Un bon code doit également être un code bien organisé, bien structuré, bien commenté, optimisé, factorisé, minimal, lisible, intelligible, avec des conventions de nommage, conforme aux standards/pratiques actuell(e)s, etc., etc.

Pour moi c'est la description d'un code propre. Et un code peut être propre sans pour autant être bon. Un code peut être propre et inclure des traitements inutiles qui le ralentisse ou provoque des erreurs dans certain cas. Et des bouts de code propre j'en ai ré-écrit pas mal aussi (en expliquant au stagiaire qui l'avait développer les raisons de cette ré-écriture, ainsi qu'en lui expliquant le nouvel algo mis en place... Bref...).

Je ne nie pas que cela puisse exister, mais avec mon expérience (intégrateur web), j'ai beaucoup de mal à imaginer la chose. Faire ça volontairement serait tout simplement vraiment trop contraignant pour le codeur.

De surcroît, s'il postule pour un nouvel emploi quel code pourrait montrer à un employeur un codeur tel que vous l'évoquez ? Et n'oubliez pas que dans le web, on peut consulter le code...

Enfin, dans le web, toujours, on travaille souvent en équipe. J'ai du mal à imaginer que quelqu'un qui fait du mauvais code (au moins) volontairement ne se fasse pas repérer tôt ou tard à tout le moins s'il n'est pas seul dans son domaine (front-end, back-end) à travailler dans la boite.

Et pourtant, je travaille sur un logiciel VBA qui est coder dans ce sens. Les tables sont remplis avec des alias. Il n'y a quasiment aucun id pour relier les tables mais toujours des string avec alias. Les champs on des nominations très alambiqué. Et le code est un ensemble de fonction de 5 lignes maximum (Et qui appel donc des sous fonctions qui elles mêmes appelles des sous fonctions qui appelles elles aussi des sous fonction qui ...) qui nous font voyager sur des dizaines de modules différents. Le mec qui à développer l'application c'est même amuser à créer des fonctions pour chaque fonction access existant. Ce qui fait qu'au lieu de faire par exemple un "Nz(Value, "")", il passe par la fonction "Isnull(Value)", rendant la lecture de sont code extrêmement difficile. Et là si t'es pas le mec qui à développer l'appli et qui sais quel syntaxe il à mis en place... Bref, ça existe :/

[xarkam]

d’ordre sécuritaire (66 %) et règlementaire (62 %)

On a peur du vol d'informations, d'intrusion dans l'infra, du social engineering. (l'ordre sécuritaire)
On veux cadrer plus fortement les employés par des règlements plus strict et précis. (En expliquant que c'est bon pour la sécurité)

concurrentiel (60 %) ou liés à la disponibilité d’une main-d’œuvre de qualité (61 %).

Le nerf de la guerre tout en voulant une main-d’œuvre de qualité payée au lance pierre pour être concurrentiel.

Bien qu’il soit prioritaire pour les cadres supérieurs d’accroitre la productivité de leurs développeurs (96 % l’ont signalé)

96% des cadres sup ne comprennent rien au travaille de développeur et les considères un peu comme des féniasses non productives.

Six développeurs sur dix jugent eux-mêmes « excessif » le temps dédié au « mauvais code »

Tout n'est que notion appréhension. Si un code est mauvais, soit il ne fait pas ce pour quoi il a été fait, soit il est pas fonctionnelle.

Qui en tant que développeur n'a pas connu un projet donc les besoins évoluent en cours de route?
Un code ne peux pas être mauvais si le besoin auquel il devait répondre a évolué.

Tant que le code fait ce pour quoi il a été codé, il n'est en rien mauvais.

Après, il est bien connu que les dev ont un égo tellement surdimensionné que cela joue aussi dans la balance.

[Tagashy]

en lisant cet article je me demande mais qu'est ce qu'il se passe dans la tête de ces gens Oo.

Je suis totalement d'accord sur le fait que c'est chiant de debugger un code pourris mais par contre c'est vital ...
Petit exemple : qu'est ce qui est le plus important entre faire fonctionner un moyen de payement qui bug suite à la mise à jour XXX du fournisseur, ou implémenter un chariot intelligent qui prédirais les achats.
Pour un dev, le deuxième point est plus intéressant que le premier mais il faut penser logique métier et dans ce cas on se rend compte que niveau criticité le premier est largement plus important ...
Je développe un soft de génération de rapport, et oui je préfère ajouter un nouveau graphe que de corriger l’alignement des colonne du tableaux X ou cherchez pourquoi les données XY qui devrais être ici n'y sont que partiellement , mais un des deux affecte le clients immédiatement et l'autre l'affecte dans le futur...

Je sais pas si je suis clair mais pour moi la maintenance est chiante mais nécessaire contrairement à ce que me laisse pensé cet article

[disedorgue]

Si au départ, il n'y avait pas de mauvais code, il n'y aurait pas besoin de le corriger