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 163PARTAGES 15 0 À 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 :



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 ? À 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. Stripe (PDF)Que pensez-vous des données exposées dans cette étude ? Une erreur dans cette actualité ? Signalez-le nous ! Votre nom : Votre e-mail : Décrivez l'erreur que vous souhaitez porter à notre connaissance : 80 commentaires Poster une réponse Signaler un problème Les mieux notés Les plus récents Ordre chronologique Expert éminent sénior https://www.developpez.com Envoyé par sebastiano Envoyé par (.../...) (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).



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). 16 0 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 lemassif 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.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). Membre éprouvé https://www.developpez.com



Il suffit de voir les réactions apporter



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 !". 14 0 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 !". Membre expérimenté https://www.developpez.com



- Une API REST c'est juste du CRUD

- La base de données en NodeJS c'est Mongo (et puis SQL on connait pas donc on zappe)

- Côté front, il faut que ça soit simple, donc on va faire un seul formulaire qui fait tout dans tous les contextes

- Pourquoi s'emmerder avec un système d'authentification ? Si on est sur cette page c'est que c'est tel type d'acteur et pour identifier le client on a qu'à faire des sous domaines.

- On va faire du SCRUM parce que c'est la mode, bien évidemment inutile de se former sur les différents rôles

- Et puis il n'y a plus qu'à presser les "codeurs" à coups de "vite vite vite, on a déjà vendu le truc"



Avec des mentalités pareilles d'apprenti sorcier, c'est même pas la peine de démarrer. 13 0 Là je sors d'une expérience pitoyable où les décideurs techniques ont décidé :- Une API REST c'est juste du CRUD- La base de données en NodeJS c'est Mongo (et puis SQL on connait pas donc on zappe)- Côté front, il faut que ça soit simple, donc on va faire un seul formulaire qui fait tout dans tous les contextes- Pourquoi s'emmerder avec un système d'authentification ? Si on est sur cette page c'est que c'est tel type d'acteur et pour identifier le client on a qu'à faire des sous domaines.- On va faire du SCRUM parce que c'est la mode, bien évidemment inutile de se former sur les différents rôles- Et puis il n'y a plus qu'à presser les "codeurs" à coups de "vite vite vite, on a déjà vendu le truc"Avec des mentalités pareilles d'apprenti sorcier, c'est même pas la peine de démarrer. Membre extrêmement actif https://www.developpez.com 12 1 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). Membre averti https://www.developpez.com



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 10 0 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 Membre éprouvé https://www.developpez.com

Envoyé par sebastiano Envoyé par 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).

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. 10 1 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...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. Expert éminent sénior https://www.developpez.com 10 1 Si au départ, il n'y avait pas de mauvais code, il n'y aurait pas besoin de le corriger Membre extrêmement actif https://www.developpez.com Envoyé par disedorgue Envoyé par Oui, mais là, on est sur une évolution, pas sur de la correction...



Et ton exemple peux aussi être vu comme du mauvais code, si celui-ci a été fait par exemple en juin 2001, alors que l'on savait déjà que le franc allait disparaitre.



Donc, la question déjà à se poser est de déterminer ce que l'on appelle du mauvais code ? 9 0 Non, ce n'est absolument pas du mauvais code. C'est de l'ordre de la définition du besoin. Membre éclairé https://www.developpez.com Envoyé par Edrixal Envoyé par 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.



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).



Envoyé par Edrixal Envoyé par 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



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. 9 0 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 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. Membre confirmé https://www.developpez.com Envoyé par Christian Olivier Envoyé par 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. ensuite une quantité de temps démesurée sur la maintenance du système branlant qui a fatalement fini par en ressortir à force de trancher les moyens disponibles au sabre. 9 0 Autre hypothèse, le budget et le temps alloué aux projets est insuffisant pour atteindre un niveau de qualité qui permette de ne pas passerune quantité de temps démesurée sur la maintenance du système branlant qui a fatalement fini par en ressortir à force de trancher les moyens disponibles au sabre. Poster une réponse Signaler un problème

