IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mars 2013
    Messages
    6 093
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : mars 2013
    Messages : 6 093
    Points : 148 566
    Points
    148 566
    Par défaut Les développeurs gèrent un volume de code 100 fois plus important maintenant qu'en 2010
    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).

    Nom : un.png
Affichages : 2059919
Taille : 7,1 Ko

    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.

    Nom : deux.png
Affichages : 14295
Taille : 17,3 Ko

    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.

    Nom : trois.png
Affichages : 14200
Taille : 21,6 Ko

    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.

    Nom : quatre.png
Affichages : 14155
Taille : 41,1 Ko

    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.

    Nom : cinq.png
Affichages : 14105
Taille : 19,7 Ko

    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.

    Nom : six.png
Affichages : 14078
Taille : 30,6 Ko

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

    Nom : sept.png
Affichages : 14046
Taille : 25,3 Ko

    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.

    Nom : huit.png
Affichages : 13987
Taille : 14,3 Ko

    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.

    Nom : neuf.png
Affichages : 13978
Taille : 20,4 Ko

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

    Nom : dix.png
Affichages : 13967
Taille : 39,5 Ko

    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 ?
    Images attachées Images attachées
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Expert confirmé Avatar de marsupial
    Homme Profil pro
    DevOp, Tech leader
    Inscrit en
    mars 2014
    Messages
    1 221
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : DevOp, Tech leader

    Informations forums :
    Inscription : mars 2014
    Messages : 1 221
    Points : 4 725
    Points
    4 725
    Par défaut
    Un point qui n'est pas abordé est la surface d'attaque du big code générant une source de failles en croissance.
    Repeat after me
    Le monsieur lutte pour la défense des libertés individuelles et collectives

    Repeat after me...

  3. #3
    Membre habitué
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2019
    Messages
    53
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2019
    Messages : 53
    Points : 195
    Points
    195
    Par défaut
    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é.

  4. #4
    Membre actif
    Inscrit en
    mai 2008
    Messages
    77
    Détails du profil
    Informations forums :
    Inscription : mai 2008
    Messages : 77
    Points : 212
    Points
    212
    Par défaut
    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.

  5. #5
    Membre expérimenté
    Profil pro
    Inscrit en
    juin 2009
    Messages
    390
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2009
    Messages : 390
    Points : 1 316
    Points
    1 316
    Par défaut
    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/

  6. #6
    Expert confirmé

    Homme Profil pro
    Développeur .NET
    Inscrit en
    novembre 2010
    Messages
    2 021
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2010
    Messages : 2 021
    Points : 4 108
    Points
    4 108
    Par défaut
    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é.
    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.

  7. #7
    Membre averti
    Homme Profil pro
    Inscrit en
    septembre 2011
    Messages
    95
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : septembre 2011
    Messages : 95
    Points : 399
    Points
    399
    Par défaut
    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....

  8. #8
    Membre habitué
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2019
    Messages
    53
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2019
    Messages : 53
    Points : 195
    Points
    195
    Par défaut
    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.

  9. #9
    Expert confirmé
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    1 203
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 1 203
    Points : 5 111
    Points
    5 111
    Par défaut
    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.

  10. #10
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Architecte Web / Android
    Inscrit en
    août 2003
    Messages
    6 300
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Architecte Web / Android
    Secteur : Industrie

    Informations forums :
    Inscription : août 2003
    Messages : 6 300
    Points : 18 123
    Points
    18 123
    Par défaut
    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
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  11. #11
    Membre averti
    Homme Profil pro
    Inscrit en
    septembre 2011
    Messages
    95
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : septembre 2011
    Messages : 95
    Points : 399
    Points
    399
    Par défaut
    Citation Envoyé par grunk Voir le message
    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/...

  12. #12
    Expert éminent sénior Avatar de disedorgue
    Homme Profil pro
    Ingénieur intégration
    Inscrit en
    décembre 2012
    Messages
    3 823
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur intégration
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : décembre 2012
    Messages : 3 823
    Points : 11 170
    Points
    11 170
    Par défaut
    Citation Envoyé par LeBressaud Voir le message
    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.
    Cordialement.

  13. #13
    Membre expérimenté
    Avatar de Madmac
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2004
    Messages
    991
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Alimentation

    Informations forums :
    Inscription : juin 2004
    Messages : 991
    Points : 1 447
    Points
    1 447
    Billets dans le blog
    3
    Par défaut
    Citation Envoyé par LeBressaud Voir le message
    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.
    intel i7
    Mint 20
    Plasma et Cinnamon

  14. #14
    Membre éprouvé

    Homme Profil pro
    Consultant ERP
    Inscrit en
    janvier 2013
    Messages
    368
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Consultant ERP
    Secteur : Conseil

    Informations forums :
    Inscription : janvier 2013
    Messages : 368
    Points : 1 255
    Points
    1 255
    Par défaut
    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!

  15. #15
    Expert confirmé

    Profil pro
    Inscrit en
    janvier 2011
    Messages
    2 830
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : janvier 2011
    Messages : 2 830
    Points : 4 087
    Points
    4 087
    Par défaut
    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.

  16. #16
    Membre éprouvé
    Homme Profil pro
    Développeur Java
    Inscrit en
    mai 2019
    Messages
    368
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : mai 2019
    Messages : 368
    Points : 1 047
    Points
    1 047
    Par défaut
    Citation Envoyé par grunk Voir le message
    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.

  17. #17
    Membre habitué
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    mai 2015
    Messages
    23
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : mai 2015
    Messages : 23
    Points : 157
    Points
    157
    Par défaut Oui mais...
    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...

  18. #18
    Membre éprouvé
    Homme Profil pro
    Programmeur du dimanche
    Inscrit en
    août 2017
    Messages
    301
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Programmeur du dimanche
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2017
    Messages : 301
    Points : 1 069
    Points
    1 069
    Par défaut
    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.
    Sur Youtube je suis "Le développeur des cavernes"
    https://www.youtube.com/channel/UCSz...bYl_pSNMv_zerQ

    Je suis aussi "Gaming des cavernes" :
    https://www.youtube.com/channel/UC5C...Hdt9ORG6lL0xcw

  19. #19
    Membre habitué
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    mai 2015
    Messages
    23
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : mai 2015
    Messages : 23
    Points : 157
    Points
    157
    Par défaut ...et en plus
    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...

  20. #20
    Membre expérimenté
    Homme Profil pro
    Ingénieur
    Inscrit en
    septembre 2002
    Messages
    2 104
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Ingénieur
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : septembre 2002
    Messages : 2 104
    Points : 1 617
    Points
    1 617
    Par défaut
    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+
    La connaissance ne sert que si elle est partagée.
    http://ms2i.net

Discussions similaires

  1. Réponses: 32
    Dernier message: 19/11/2020, 08h00
  2. Réponses: 30
    Dernier message: 16/03/2015, 14h52
  3. Réponses: 6
    Dernier message: 09/10/2014, 15h14
  4. Réponses: 53
    Dernier message: 06/06/2012, 13h54
  5. Des disques durs 100 fois plus rapides bientôt disponibles ?
    Par Hinault Romaric dans le forum Actualités
    Réponses: 25
    Dernier message: 16/02/2012, 11h29

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo