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 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.
Une complexité qui a un impact personnel sur eux

Le , par Stéphane le calme

696PARTAGES

15  0 
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 ?

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

Avatar de LeBressaud
Membre averti https://www.developpez.com
Le 02/10/2020 à 10:56
Citation Envoyé par user056478426 Voir le message
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....
16  1 
Avatar de PomFritz
Membre habitué https://www.developpez.com
Le 01/10/2020 à 22:01
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.
10  0 
Avatar de OuftiBoy
Membre régulier https://www.developpez.com
Le 13/10/2020 à 10:11
En effet, on avait tout ce qu'il fallait...
Mon "parcours", c'est :

- Basic sur C64 en 1985/86
- Pascal / C / ASM pendant les études 1990/1992

- C pour l'embarqué (sans OS), en attaquant directement le Hardware.
- C pour Win3.1 pour faire un "Device Driver" avec le DDK "Device Development Kit" (20 disquettes à l'époque pour l'installation, pas de doc ou très peu)

- C++ (C++ Builder de Borland pour être exact) pour du dev Desktop. (ça évitait les MFC...)
- J'ai arrêté de m'intéresser au C++ quand son arrivés les "Template", et m'être tapé le bouquin d'Alecsendrescu (700 pages, rien que sur le sujet des templates...). Premier déclic. Syntaxe obscure, complexité inutile, et ça ne c'est pas arrangé depuis...

Maintenant, 30 ans plus tard...
- C'est toujours C mais avec un petit RTOS pour l'embarqué
- WxPython (et donc Python) pour le desktop

Je me marre quand j'entends certains se vanter de connaître 25 langages. Il faut des années pour maîtriser un langage. Regardez 3 tutos sur "Rust" ne fait pas de toi un "Développeur" Rust.

J'ai 1 règle d'or... Le code source d'un "programme" se code 1x, se lit des milliers de fois, ma priorité va donc à la lisibilité du code.

Sinon, on en arrive vite à des soupes immondes, remplies d'inepties, de copier/coller et on arrive à un brol non maintenable... Donc faut pouvoir "lire" le source d'un programme aisément, éviter d'utilisé la dernière fonctionnalité à la mode (la nouvelle syntaxe obscure "génial"), rester simple [KISS] et humble...

La "programmation" exige de la rigueur, c'est un exercice (une démarche) très compliquée... Je n'appelle pas "programmer" le fait d'assembler des bouts de code, de copier/coller des parties entière au lieu de refactoriser dès que nécessaire, d'utiliser (trop) de choses (librairie, outils) "externe" instable (effet mode).

Il faut du solide, un socle sur lequel on peux se reposer en toute confiance, qu'on maîtrise vraiment (pas juste "connaître)...

C'est pour ça que j'ai jamais voulus "toucher" au développement web. Rien n'est stable (langage/framework), ça "évolue" en permanence, et 2 ans plus tard, faut tout refaire avec le dernier "framework" à la mode...

Par analogie, en médecine, un généraliste ne s'essayerait pas à une greffe de fois, et un dentiste ne te proposerait pas de t'opérer d'une fracture de la jambe...
10  0 
Avatar de OuftiBoy
Membre régulier https://www.developpez.com
Le 08/10/2020 à 19:05
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...
9  1 
Avatar de user056478426
Membre habitué https://www.developpez.com
Le 02/10/2020 à 14:10
Citation Envoyé par youtpout978 Voir le message
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.
6  0 
Avatar de marsupial
Expert confirmé https://www.developpez.com
Le 01/10/2020 à 18:09
Un point qui n'est pas abordé est la surface d'attaque du big code générant une source de failles en croissance.
5  0 
Avatar de user056478426
Membre habitué https://www.developpez.com
Le 01/10/2020 à 19:22
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é.
6  1 
Avatar de OuftiBoy
Membre régulier https://www.developpez.com
Le 12/10/2020 à 11:43
Le lien donné dans la signature du message précédent : https://ms2i.net/
est très démonstratif des dérives de ce que devient le web et de l'influence néfaste des smatphones dont je me plaignait un peu avant dans la discussion...

Nous voici donc en 2020, avec une "page web" ayant un bouton "Home", qui disparait lorsque l'on "scroll" la page, et qui ne sert en faite à rien, puisque si on le voit, c'est qu'on est au début haut de la page et quand on en aurait besoin pour "remonter" en haut de la page, il n'est plus visible...

Les (bons) sites web "à l'ancienne", proposaient une barre de menu, qui restait visible rendant la navigation bien plus pratiques...

Autre dérive, à quoi peut bien servir d'augmenter la taille/résolution des écrans si c'est pour n'y écrire qu'en plus grand moins d'information ? Les "sites web modernes" (adaptés pour smartphones) sont juste une abération. Il y avait plus d'info et la navigation (sur desktop) était plus simple, rapide, sur un écran VGA en 2000 que sur l'utilisation qu'on fait maintenant d'un écran "full HD" (si pas plus)...

Si en 2020 on n'est plus capable que de faire des "sites" de la sorte, inadaptés aux "desktop", oui, ça doit être a cause du COVID ;-)
8  3 
Avatar de Pyramidev
Expert confirmé https://www.developpez.com
Le 02/10/2020 à 14:35
Citation Envoyé par LeBressaud Voir le message
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.

Citation Envoyé par LeBressaud Voir le message
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.
4  0 
Avatar de grunk
Modérateur https://www.developpez.com
Le 02/10/2020 à 16:54
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
4  0