Discussion :

[Stéphane le calme]

Les développeurs gèrent un volume de code 100 fois plus important maintenant qu'en 2010
dans plus de langages, pour plus de plateformes que jamais et la moitié d'entre eux ont parfois peur lorsqu'ils publient du code

Sourcegraph, une entreprise spécialisée dans la recherche universelle de codes, a interrogé plus de 500 développeurs de logiciels nord-américains pour identifier les problèmes liés à la complexité et la gestion du code. Ses conclusions générales ne sont probablement pas une surprise pour de nombreux lecteurs de developpez.com (dans la mesure où les logiciels sont devenus de plus en plus volumineux, de plus en plus complexes et beaucoup plus importants au cours des dix dernières années), mais leur portée peut être surprenante.

Selon Sourcegraph, le Big Code est tout ce qui a trait à la façon dont le code se développe en :

• Volume : augmentations exponentielles de la quantité de code.
• Variété : beaucoup plus de complexité dans les langages, les outils et les processus utilisés pour fournir des logiciels.
• Vitesse : cycles de livraison accélérés, ce qui signifie que le code change plus rapidement et est livré pratiquement tous les jours.
• Valeur : la réimagination des modèles commerciaux et des pratiques grâce à des logiciels de haute qualité.

Pour cette enquête, Big Code fait référence à la croissance spectaculaire du volume et de la complexité du code. Cela comprend l'augmentation de la variété des environnements de développement, des plateformes et des outils; la rapidité des calendriers de livraison; et la valeur commerciale attendue. Le Big Code a un impact sur les équipes de développement comme le Big Data a eu un impact sur les équipes de données.

Sourcegraph précise que « Ce rapport est basé sur une enquête menée en 2020 auprès de plus de 500 professionnels du développement logiciel en Amérique du Nord. Cette recherche examine l'état du Big Code pour quantifier sa complexité, comprendre son impact réel sur le développement et les résultats commerciaux et identifier ce qui doit être changé pour que les entreprises réussissent. Tous les participants à l'enquête avaient la responsabilité directe du développement logiciel dans une entreprise de plus de 200 employés de développement ».

Dans les bases de code vastes et complexes d’aujourd’hui, il est invariablement problématique pour les développeurs de découvrir, comprendre et corriger le code en raison de l’augmentation significative du volume et de la complexité du code. Le Big Code est l'un des problèmes les plus urgents auxquels les entreprises de logiciels sont confrontées aujourd'hui. Parce que les logiciels sont une partie importante de chaque industrie, le Big Code a un impact sur presque toutes les organisations avec des efforts de développement importants (94%, d'après le sondage).

Ce niveau de réponse est presque identique dans toutes les organisations et industries, quel que soit leur taille ou le nombre spécifique de développeurs. Il est intéressant de noter que les industries en dehors du logiciel rapportent qu'elles sont un peu plus touchées, 95 % déclarant être touchées par le Big Code contre 92 % des éditeurs de logiciels. Ces données soutiennent la réalité actuelle selon laquelle le Big Code n'est pas seulement un problème de l'industrie du logiciel.

Les évolutions

Croissance du volume

Pour mieux comprendre ce qui est en jeu, il est important de commencer par quantifier la taille du Big Code. En d'autres termes, avec quels volumes de code les organisations travaillent-elles en 2020 s'il fallait comparer par exemple à 2010 ? Lorsqu'il leur a été demandé comment la taille de la base de code dans l'ensemble de leur entreprise, mesurée en mégaoctets et le nombre de référentiels, a changé au cours de la dernière décennie, plus de la moitié (51 %) des parties prenantes du développement logiciel déclarent avoir plus de 100 fois le volume de code d'il y a 10 ans. Et 18 % d'entre eux déclarent avoir 500 fois plus de code.

Une plus grande variété

Lors de l'examen des logiciels actuels, il est essentiel de noter la profusion de différents langages de programmation, référentiels, systèmes de contrôle de version, architectures, services, appareils pris en charge, outils, API, etc. qui contribuent à la complexité et au volume du code. Plus précisément, plus de six professionnels du logiciel sur 10 signalent une augmentation significative dans un large éventail de dimensions de développement différentes au cours de la dernière décennie.

La vitesse augmente

En plus du volume et de la variété qui sont en pleine expansion au sein du Big Code, la vitesse de diffusion des versions de logiciels augmente également. Grâce à la mise en œuvre d'approches et de pratiques de développement telles qu'Agile, Scrum et DevOps, les organisations peuvent effectuer des builds plus rapides et déployer rapidement de nouvelles versions. Presque tous les acteurs du développement (92 %) disent qu'il y a une pression croissante au cours des 10 dernières années pour publier le code plus rapidement.

Le Big Code pose de gros problèmes

Les équipes de développement sont confrontées à de nombreuses difficultés en raison d'une complexité croissante des logiciels qui soutiennent l'entreprise. Si l'entreprise devient de plus en plus complexe, sa base de code suivra, car le développement reflète l'entreprise et ses processus clés. Lorsqu'ont été interrogés les acteurs du développement logiciel sur la complexité de leur logiciel, 77 % ont déclaré qu'il est considérablement plus complexe qu'il y a 10 ans.

Comme cela pouvait être prévisible, cette augmentation spectaculaire de la complexité du code présente un large éventail de défis pour les équipes de développement. Le principal défi cité est le temps et les efforts nécessaires pour que les nouvelles recrues soient productives (62 %), suivis de la rupture de code en raison d'un manque de compréhension des dépendances (57 %), des difficultés à gérer les changements de code (50 %), du manque de visibilité (46 %), des révisions de code lentes (43 %), une frustration accrue pour les développeurs qui trouvent du code spécifique (40 %), des problèmes de compréhension de nouvelles bases de code (38 %), et bien plus encore. Quelques personnes ont évoqué d'autres problèmes auxquels ils faisaient face comme le maintien de la qualité, le manque de connaissances en matière de test, la courbe d'apprentissage des nouvelles technologies et le temps de traitement.

La complexité du Big Code a un impact direct sur l'entreprise

Avec des milliards de lignes de code, de multiples interfaces système et des exigences complexes, la complexité du logiciel peut influencer le contrôle de l'équipe de développement et entraîner des conséquences commerciales indésirables. La complexité du Big Code est une préoccupation majeure pour les équipes gérant de nombreuses technologies et applications. Dans cette étude, 99 % des acteurs du développement établissent une corrélation directe entre la complexité du code et l'impact sur l'entreprise. Selon les parties prenantes, les principaux résultats commerciaux négatifs liés au Big Code sont la difficulté à maintenir des normes de qualité élevées (57 %), des risques de sécurité élevés (51 %), des délais de publication retardés (49 %), des coûts accrus (47 %), moins d'agilité ( 46 %) et une difficulté croissante à innover (36 %).

La complexité du Big Code a un impact personnel sur les développeurs

Sur un plan plus personnel, presque toutes les nouvelles versions de logiciels complexes suscitent des sentiments indésirables, 88 % des équipes de développement de logiciels admettant que chaque version provoque une certaine anxiété.

Lorsque la question a été approfondie, les développeurs ont révélé qu'ils ressentent un large éventail d'émotions lors de la publication de code. Presque toutes les équipes de développement (96 %) révèlent que les versions de code suscitent des émotions en eux. Bien que beaucoup rapportent des sentiments positifs comme la satisfaction, il est alarmant de constater que plus de la moitié (58 %) disent ressentir des émotions négatives, y compris la peur et l'anxiété, au moment où ils publient le code ou le soumettent pour examen.

Les équipes évitent de mettre à jour le code, car elles craignent de briser les dépendances

L'une des révélations les plus sombres de cette enquête est de savoir comment cette peur peut affecter les progrès du développement. Les trois quarts (74 %) des acteurs du développement affirment que leurs équipes évitent de mettre à jour le code, car elles ne sont pas sûres des dépendances et craignent de casser quelque chose.

Les équipes de développement ont besoin de nouveaux outils pour s'adapter aux environnements Big Code

Les outils existants n'ont pas été conçus pour l'ère du Big Code

Les éditeurs et les EDI ont été conçus pour des développeurs individuels travaillant en petites équipes sur un référentiel unique. Mais dans l'environnement actuel, les développeurs collaborent désormais régulièrement sur du code à grande échelle. Pour répondre aux exigences de l'entreprise et rester compétitifs, ils doivent évoluer rapidement, même dans les grandes bases de code. Mais leurs outils actuels peuvent-ils s'adapter aux environnements Big Code ? Une écrasante majorité de développeurs de logiciels (85 %) est d'accord pour dire que les outils existants ne sont pas conçus pour travailler avec de grandes bases de code à grande échelle.

En particulier, comment les développeurs effectuent-ils des recherches dans des bases de code massives pour écrire et apporter des modifications efficaces au code de leur entreprise tout en respectant des délais serrés dans le cadre d'exigences strictes en matière de qualité et de sécurité ? Interrogées sur la technologie utilisée pour effectuer des recherches dans le code d'entreprise, les équipes logicielles déclarent s'appuyer sur des hôtes de code (83 % - GiHub, GitLab, BitBucket, etc.), des outils locaux (69 % - EDI/éditeurs, etc.), des outils de recherche de code open source (35 % - OpenGrak, Hound, LiveGrep, etc.), une recherche de code universelle (24%), et plus encore. Plusieurs personnes ont pris le temps d'écrire d'autres réponses, notamment Team Foundation Server (TFS), Azure DevOps, ClearCase, des solutions maison, des hôtes de code interne, Jira, Resharper, SCCS et Codeproject.

En y regardant de plus près, il existe un écart alarmant entre ce que la direction pense que ses développeurs utilisent pour effectuer la recherche de code et ce que les développeurs rapportent utiliser. Parmi les dirigeants, 50 % déclarent que leurs développeurs utilisent la recherche de code universelle, tandis que seulement 13 % des développeurs utilisant ces outils rapportent la même chose.

Les équipes de développement bénéficieraient de capacités supplémentaires pour rechercher du code

Alors que la direction et les développeurs ne sont pas synchronisés sur les outils de recherche qu'ils utilisent actuellement, ils conviennent de vouloir de nouvelles technologies ayant le potentiel de transformer les entreprises à court terme. Presque toutes les parties prenantes du développement (99%) disent qu'elles bénéficieraient de capacités supplémentaires de recherche de code.

Les deux tiers (67 %) affirment que la possibilité de configurer des alertes pour les vulnérabilités de sécurité et les risques de conformité serait la plus précieuse pour leurs équipes de développement. D'autres fonctionnalités principales citées par les parties prenantes impliquent la possibilité de rechercher rapidement tout le code dans n'importe quel référentiel, n'importe quel langage, tout changement de code, la possibilité de rechercher n'importe quel format de fichier (59 %), la possibilité de trouver du code en interrogeant les relations sémantiques (58 %).

Source : Sourcegraph

Et vous ?

Que pensez-vous de ces statistiques ?
Partagez-vous l'avis du panel qui indique que le volume de code, la complexité des applications, la variété des plateformes et langages, mais aussi les cycles de livraisons ont considérablement augmentés ces dix dernières années ?
Êtes-vous surpris par le fait que la complexité du Big Code ait un impact personnel sur les développeurs ?
Bien que beaucoup de développeurs rapportent des sentiments positifs comme la satisfaction, plus de la moitié (58%) disent ressentir des émotions négatives comme la peur et l'anxiété au moment où ils publient le code ou le soumettent pour examen. Qu'en pensez-vous ? Dans quel spectre vous situez-vous ?
Partagez-vous l'avis selon lequel les outils existants n'ont pas été conçus pour l'ère du Big Code ?

[marsupial]

Un point qui n'est pas abordé est la surface d'attaque du big code générant une source de failles en croissance.

[user056478426]

C'est pas pour éviter tous ces problèmes qu'on met en place des tests et qu'on fait du TDD ? Je n'ai pas peur de modifier un bout de code qui est testé, puisque je sais très vite si mes changements cassent son fonctionnement. Et si je dois modifier du code non testé, je test d'abord la version actuelle avant de la modifier. De mon point de vu si on a peur des versions c'est qu'on a pas confiance en notre projet, probablement parce que le processus de déploiement n'est pas bon ou pas assez automatisé.

[PomFritz]

C'est pas pour prêcher pour ma paroisse, mais peut-être qu'il y en aura pour comprendre qu'il serait bien de privilégier un peu plus l'expérience au pissage de code. Rien d'étonnant, c'est le résultat de la productivité à court terme. Le règne du script. Les outils n'ont pas plus évolué qu'un traitement de texte, un manque d'imagination et un conservatisme effarants.

[walfrat]

Je ne suis pas expert mais je pense que cet article n'insiste pas assez sur à quel point ce qu'on fait est différent de 2010 (et surtout 2005- je dirais).

Ne serait ce qu'en terme d'IHM, on nous demande des trucs toujours plus complexe et complet, forcément ça augmente la taille du code.

Prenez n'importe quel librairie qui vous permet de faire un tableau, maintenant utiliser là pour faire des tableaux intelligent a scroll infini, rendu des colonnes personnalisé, des filtres bien léché et ce sur chaque type d'objet métier de votre appli. Même avec une librairie pour vous supporter, ça prend bien plus de code qu'un vieux tableau HTML avec un formulaire au dessus qui fait une requête à l'ancienne (sans AJAX)=) à du PHP.

Enfin il faut considérer deux choses :

• Les projets non abandonnées depuis 2010 sont toujours là et font donc toujours partie de la base de code actuelle, plus tout les nouveaux projets
• Le nombre de développeurs (au sens personne embauché pour faire du développement + hobbyiste) ne fait qu'augmenter et donc la base de code https://programmation.developpez.com...ient-des-pros/

[youtpout978]

C'est pas pour éviter tous ces problèmes qu'on met en place des tests et qu'on fait du TDD ? Je n'ai pas peur de modifier un bout de code qui est testé, puisque je sais très vite si mes changements cassent son fonctionnement. Et si je dois modifier du code non testé, je test d'abord la version actuelle avant de la modifier. De mon point de vu si on a peur des versions c'est qu'on a pas confiance en notre projet, probablement parce que le processus de déploiement n'est pas bon ou pas assez automatisé.

Malheureusement le TDD est très rare, sur les dizaines de projets sur lesquels j'ai bossés pour de nombreuse boites différentes on a jamais mis en place de TDD.
La seule fois où j'ai vu ça c'est lors d'un entretien pour une boite qui faisait des systèmes de vidéo surveillance.

[LeBressaud]

C'est pas pour éviter tous ces problèmes qu'on met en place des tests et qu'on fait du TDD ? Je n'ai pas peur de modifier un bout de code qui est testé, puisque je sais très vite si mes changements cassent son fonctionnement. Et si je dois modifier du code non testé, je test d'abord la version actuelle avant de la modifier. De mon point de vu si on a peur des versions c'est qu'on a pas confiance en notre projet, probablement parce que le processus de déploiement n'est pas bon ou pas assez automatisé.

Il y'a vraiment des gens qui font du TDD ? J'en ai jamais croisé à part sur certains petits projets fait par des stagiaires qui ont beaucoup de temps à perdre. Dans la majorité des cas il n'y a même pas le temps d'écrire du code correct, alors commencer par écrire des tests pour des spécs qui vont changer à la première démo....

[user056478426]

Malheureusement le TDD est très rare, sur les dizaines de projets sur lesquels j'ai bossés pour de nombreuse boites différentes on a jamais mis en place de TDD.
La seule fois où j'ai vu ça c'est lors d'un entretien pour une boite qui faisait des systèmes de vidéo surveillance.

Je sais pas toi mais moi je ne rejoins pas une boite qui n'a pas compris l'intérêt des tests, ou qui n'en fait pas. Suivre la méthodologie TDD à la lettre n'est pas indispensable, l'important c'est que le code soit bien testé. Moi même je commence pas toujours par écrire les tests avant de coder, notamment sur les projets où les specs sont encore approximatives. Mais à moins d'être sûr que tu ne vas jamais retoucher au code plus tard (e.g: un projet d'école que tu vas juste présenter puis oublier), les tests sont indispensables.

Sinon pour le TDD, ça apporte pas mal d'avantages comme le fait de réfléchir dès le début à l'organisation de ton code et la cohérence des specs. Ça te fait aussi gagner beaucoup de temps sur les futurs refacto : tu n'as qu'une commande à lancer pour savoir si ça fonctionne. Je sais bien que c'est pas facile de l'appliquer tout le temps, mais le faire le plus souvent possible ne peut que te rendre meilleur et plus productif. De ce que j'ai vu sur les projets open source qui l'appliquent le mieux, le code peut être négligé mais les tests eux sont très soignés. De sorte à privilégier l'aspect fonctionnel et pouvoir repasser sur les perfs/qualité du code sans problème.

[Pyramidev]

Il y'a vraiment des gens qui font du TDD ?

Quand j'implémente une nouvelle fonctionnalité, le code est recouvert par des tests unitaires. Concernant l'ordre dans lequel j'écris les bouts de code de production et les tests, il arrive que ce soit en TDD, mais pas systématiquement. Ça dépend de ce que je code.

Dans la majorité des cas il n'y a même pas le temps d'écrire du code correct, alors commencer par écrire des tests pour des spécs qui vont changer à la première démo....

Dans ces cas là, il y a ÉNORMÉMENT de temps pour se débattre avec l'existant, perdre de longues heures en support, corriger des bogues, etc. Ça prend tellement de temps qu'il faut plusieurs personnes pour faire le travail d'une seule.

[grunk]

Partagez-vous l'avis du panel qui indique que le volume de code, la complexité des applications, la variété des plateformes et langages, mais aussi les cycles de livraisons ont considérablement augmentés ces dix dernières années ?

Au contraire j'aurais tendance à dire que les cycles de livraison se sont simplifié depuis 10 ans , notamment grâce aux outils de CI/CD qui sont maintenant mature et pour certains plutôt simple à implémenter.

La complexité des applis et la variété des plateformes c'est probablement la fautes à la mode des microservices. Là oà avant on allait faire une application monolithique en (insérer ici le langage qui vous plait) la mode est à scinder cette appli en plein de petit services. Et en général chacun y va de son langage favoris. Du coup ca devient le bordel tant d'un point vu dev que ops.

Il y'a vraiment des gens qui font du TDD ?

Au sens strict du terme doit pas y'en avoir des masses. En revanche du test unitaire écrit un peu quand on à le temps, je pense que c'est assez courant. Les avantages ne sont plus à démontrer. Il n'y'a finalement que le niveau de coverage qui pourrait être discutable

[LeBressaud]

Au sens strict du terme doit pas y'en avoir des masses. En revanche du test unitaire écrit un peu quand on à le temps, je pense que c'est assez courant. Les avantages ne sont plus à démontrer. Il n'y'a finalement que le niveau de coverage qui pourrait être discutable

Oui je l'entendais dans ce sens, en général ca se limite aux fonctions critiques et je pense que c'est suffisant dans la majorité des cas. Je vois pas trop l'intérêt de faire des test pour faire des tests et jouer à avoir un gros code coverage, sauf gros projet avec beaucoup de turn over et donc beaucoup de dev débutant/reconvertit/mauvais/...

[disedorgue]

Oui je l'entendais dans ce sens, en général ca se limite aux fonctions critiques et je pense que c'est suffisant dans la majorité des cas. Je vois pas trop l'intérêt de faire des test pour faire des tests et jouer à avoir un gros code coverage, sauf gros projet avec beaucoup de turn over et donc beaucoup de dev débutant/reconvertit/mauvais/...

Si, l'utilité de faire des tests qui couvrent tout dans tous les sens, c'est utile pour des projets qui ont une très longue durée de vie sur lesquels on vous demande de rajouter de nouvelles specs car bien souvent la nouvelle specs fait contre sens d'une très ancienne et pas remise au gout du jour...
Et là, que l'on soit débutant/reconvertit ou expert (je laisse de coté le mauvais) , on galère dans ce nœud de spaghetti.

Il ne faut pas oublier qu'il existe encore du très vieux code, sans commentaire le rattachant à une specs ou fonction particulière voir même borderline dans la version du langage de l'époque.

Perso, je pense qu'on y gagnerait en supprimant les TMA qui sont payées à la ligne de code: ça éviterait peut-être déjà de se retrouver avec 5 fois la même classe/fonction de plusieurs centaines de lignes dont la seule chose qui les différencie c'est le nom et/ou un paramètre.

[Madmac]

Il y'a vraiment des gens qui font du TDD ? J'en ai jamais croisé à part sur certains petits projets fait par des stagiaires qui ont beaucoup de temps à perdre. Dans la majorité des cas il n'y a même pas le temps d'écrire du code correct, alors commencer par écrire des tests pour des spécs qui vont changer à la première démo....

Oui, mais seulement en Ruby. Parce ce le langage a été pensé pour faciliter les tests. Je teste systématique mes classes. À moins que ce ne soit que des contenants. Mais en général, ça ce limite à vérifier l'initialisation quand je désire un mécanisme de contrôle de classe. Ou de format pour écriture dans une base de donnée.

[MaximeCh]

C'est vrai que c'est fatiguant.
Je me suis intéressé au projet de wiki Wiki.js.
Ca fait toucher à postgres, linux&coreutils, docker voire kubernetes, azure CI/CD, nodejs, de l'ORM vite fait, webpack, vuejs, graphql...

Et avec la compilation incrémentielle et tous ces robots de partout qui vont plus vite, il n'y a même plus le temps d'un baby pendant que ça compile!

[tanaka59]

Bonjour,

Les développeurs gèrent un volume de code 100 fois plus important maintenant qu'en 2010

Que pensez-vous de ces statistiques ?

C'est du à l'essor du Big Data e.

Plus de volume de data , donc plus de programmes avec plus de règles de contrôles et gestion, plus complexe au passage ...

Partagez-vous l'avis du panel qui indique que le volume de code, la complexité des applications, la variété des plateformes et langages, mais aussi les cycles de livraisons ont considérablement augmentés ces dix dernières années ?

Les chaînes de traitements de sont de plus en plus complexe à maintenir , car les règles à y appliquer sont de plus en plus complexe. Donc il parait logique que les délais de livraisons augmentent. A chaque fois dev/test/recette/prod + un nombre incalculable de décideurs qui doivent donner des avals. Mathématiquement le temps de traiter les updates et upgrades augmentent.

Etes-vous surpris par le fait que la complexité du Big Code ait un impact personnel sur les développeurs ?

Non. C'est même logique. Le nombre de facteurs et de params à prendre en compte est croissant, "intellectuellement" et sur le plus de la réflexion / logique de réflexion les développeurs doivent composer avec beaucoup de règles. Le risque d'oublier un facteur augmente aussi mécaniquement ... Le cerveau travaille plus et se fatigue aussi plus vite ...

Bien que beaucoup de développeurs rapportent des sentiments positifs comme la satisfaction, plus de la moitié (58%) disent ressentir des émotions négatives comme la peur et l'anxiété au moment où ils publient le code ou le soumettent pour examen. Qu'en pensez-vous ?

Dans les systèmes complexes avec un nombre croissant de règles, le risque d'erreur augmente statistiquement. La pression qui repose sur les développeurs augmentent donc aussi ...

Partagez-vous l'avis selon lequel les outils existants n'ont pas été conçus pour l'ère du Big Code ?

C'est vrai.

Actuellement je travaille dans le domaines des services administratif dans l'industrie (donc pas un service informatique). On travaille on "mode cloud" via sharepoint sur des Excel, word , power point partagés ...

J'ai du mal à voir des développeurs , programmeurs et codeurs en "real time" , chacun lancer une instance depuis le même programme sur un espace/pc/serveur . En imaginer un genre de bureau virtuel ou tout le monde fait tout en même temps ...

Appliqué à l'info et l'it c'est difficile de calquer sur les autres services ou l'on code mois voir pas du tout ...

On a bien les VM et les système d'instance en BDD .

Le domaine de l'informatique, BI, IT, data est bien trop spécifique et régis par des spec, pour essayer d'appliquer des raisonnement empirique d'autres domaines d'activités.

[L33tige]

Au contraire j'aurais tendance à dire que les cycles de livraison se sont simplifié depuis 10 ans , notamment grâce aux outils de CI/CD qui sont maintenant mature et pour certains plutôt simple à implémenter.

La complexité des applis et la variété des plateformes c'est probablement la fautes à la mode des microservices. Là oà avant on allait faire une application monolithique en (insérer ici le langage qui vous plait) la mode est à scinder cette appli en plein de petit services. Et en général chacun y va de son langage favoris. Du coup ca devient le bordel tant d'un point vu dev que ops.



Au sens strict du terme doit pas y'en avoir des masses. En revanche du test unitaire écrit un peu quand on à le temps, je pense que c'est assez courant. Les avantages ne sont plus à démontrer. Il n'y'a finalement que le niveau de coverage qui pourrait être discutable

Enfin, à l'époque ou yavait une appli monolithique c'était pareil, vu que les gens dans un autre service avaient besoin juste d'un petit bout de l'application, plutot que de changer d'outil, ils faisaient un copier/coller de cette partie pour l'intégrer à la leur, et au final on se retrouvait avec 15 apps, qui fonc grosso merdo la même choses, maintenues ou pas par des personnes différentes, les micro services ont l'avantage d'avoir (par app) une dette technique moindre.

[OuftiBoy]

On doit utiliser des tas de lib non écrite en interne, qui changent ts les 6 mois. On nous demande de plus en plus d'assembler des bloc qu'on a pas le temps de maîtriser, dont on ne connait rien de l'intérieur, pour faire plaisir à un manager qui veut "être à la pointe de l'innovation"...

Aussi, le web a massacré pas mal de chose :

- des pisseurs/copieurs de code ne comprenant rien à ce qu'il font, faut juste "que ça semble marcher".

- Je déteste TOUTES les interfaces Web, aucune n'est clair, n'a de sens...
Imaginez, il y a 20 ans, faire une appli desktop où quand vous cliquiez un bouton, et suite à un "refresh de page", c'est un autre bouton qui prend l'event... Tous le monde aurait pris ça comme une erreur, maintenant ça arrive tout le temps avec les appli web de merde qu'on doit se taper...

- La formation laisse a désirer... Je passe peut-être pour un vieux con, mais "programmer" sans rien connaitre du C ou de l'assembleur (sur quoi TOUT est basé), c'est comme si un maçon ne savait pas utiliser une truelle...

- Puis sont arriver les "smartphone" (qui n'ont de smart que le nom selon moi), imposant leur "flat design" même aux appli desktop qui était bien plus clair avant... Qui préfère réellement une appli "ModernUI" à une bonne vielle appli "Win32" où tout était plus clair/ranger...

Bref, on va droit dans le mur et les failles se multiplient a force d'ajouter des couches sur des couches sur des couches...

[Jamatronic]

Personnellement je ne gère pas du tout une base de code 100 fois plus grande qu'en 2010, et en fait je ne comprends même pas ce que cela peut vouloir dire.

Surtout dans un monde de gros nuls où être capable d'écrire 100 lignes de code par jour te fait passer pour un génie.

[OuftiBoy]

Il y a tous ces fameux "outils", pour créer une App sans écrire une seule ligne de code... :-)

C'est comme la mode, ça revient tj après qlq années. De mon temps, on appelait cela des outils "Case".
Un prof m'avait même dit à l'époque (en 1990), qu'on devrait bientôt se recycler et changer de métier car on n'aurait bientôt plus besoin de programmeur "dans les 5 ans"... (on ne disait pas encore "Développeur" à l'époque :-)

Le problème de ces outils, en plus d'être des usines à gaz, dès qu'il y a un problème, c'est qu'il n'y a plus personne pour descendre dans les couches et surcouches de tous ces brol... 30 ans plus tard, on en est toujours au même point...

C'est aussi pour cela que les "bons" programmeurs sont moins bien payé que les gens de l'IT. Eux ils font acheter des outils à la boite, lui fait pisser 3000 lignes de code à la seconde, et se cachent derrière un juteux contrat de "maintenance" au premier soucis. Donc qd ça "fonctionne" vite, c'est grâce à eux, et qd ça va mal, c'est à cause du "consultant" qui a à peine eu le temps de lire l'étiquette sur la boite qu'il du vendre comme "la" solution miracle...

Dans qlq années, qd les vrais/bons programmeurs auront passés l'arme à gauche, le château de carte va s'écrouler...

[Mister Nono]

Bah, avant c'était la faute à l'informatique quand quelque chose ne fonctionnait pas : maintenant c'est la faute à la COVID.

Donc tout va bien pour l'informatique...

A+