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

Débats sur le développement - Le Best Of Discussion :

La qualité du code a-t-elle foutu le camp chez les programmeurs ?


Sujet :

Débats sur le développement - Le Best Of

  1. #1
    Expert éminent sénior

    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    Mars 2013
    Messages
    426
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux
    Secteur : Enseignement

    Informations forums :
    Inscription : Mars 2013
    Messages : 426
    Points : 32 561
    Points
    32 561
    Par défaut La qualité du code a-t-elle foutu le camp chez les programmeurs ?
    La qualité du code a-t-elle disparu chez les programmeurs ?
    Un expert s'exprime sur la question

    Dans les débuts de l’informatique, le code était réservé à l’élite. Mais, avec l’avènement du phénomène internet, ce n’est plus le cas. Les ressources traitant des concepts exposés en informatique sont facilement accessibles.

    Cependant, alors que la logique voudrait aussi que la qualité du code s’améliore avec le temps, c’est l’inverse qui se produit. Qu'est-ce qui peut expliquer ce phénomène ?

    Leslie Lamport, directeur de la recherche chez Microsoft Research et détenteur du prix Turing 2013,a sa petite idée sur la question. Selon lui, aujourd’hui, la grande majorité des programmeurs passent à côté de l’essentiel. Ils sont trop pressés d’écrire le code. Or, pour tout projet qui se respecte quelque soit le domaine, l’étape de la planification est vitale.

    Pour étayer ses propos, l’expert a fait une analogie avec le domaine de l’architecture. Un architecte fait toujours un plan détaillé d’une bâtisse avant sa réalisation sur le terrain. Certes, même si ce plan ne garantit pas à 100% la solidité de l’édifice, l’architecte ne peut s’en passer, tout simplement parce que sans lui, il obtiendrait de très mauvais résultats. Pourquoi pas le programmeur ?



    Leslie Lamport

    À la différence de l’architecte, le programmeur ne fait pas de plan, mais doit réaliser des spécifications logicielles avant de se lancer dans la phase du code. Sauf qu’en pratique, ce n’est pas le cas. L’expert constate que la plupart évitent cette phase pour se lancer directement dans le code. Ils pensent à tort ou à raison qu’écrire des spécifications logicielles constitue un frein pour eux. « Ça n’aide pas à écrire le code. Et puis de toute façon, si un bogue survient, il est très facile de modifier quelques lignes de code pour tout réparer ».

    Leslie pense qu’ils ont tout simplement tort. Pour lui, même si les spécifications ne sont pas du code, elles conduisent à produire du très bon code. De plus, selon sa propre expérience, elles aideraient dans la phase de maintenance logicielle en simplifiant celle-ci.

    Alors, comment écrire de bonnes spécifications logicielles ? Il n’existe pas de règle absolue d’après l’expert. Cependant, il pense que la mathématique serait d’un apport appréciable avec des notions comme les ensembles, les fonctions et la logique.

    Source: Wired

    Et vous ?

    Êtes-vous d'accord avec l'expert ?

  2. #2
    Expert éminent sénior
    Avatar de Paul TOTH
    Homme Profil pro
    Freelance
    Inscrit en
    Novembre 2002
    Messages
    8 964
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Freelance
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2002
    Messages : 8 964
    Points : 28 430
    Points
    28 430
    Par défaut
    non je ne suis pas tout à fait d'accord.

    1) des programmeurs avec deux mains gauches il y en a toujours eut.
    2) avec la généralisation d'Internet on a beaucoup de programmeurs du dimanche, mais je ne suis pas certain qu'ils soient proportionnellement plus nombreux

    ensuite il oublie que dans l'information il y a plusieurs métiers, et que quand on demande à un seul individu de tout faire, y'a des ratés.

    au cours de ma carrière de développeur j'ai rarement eut affaire à un bon chef de projet. En fait pendant longtemps j'ai pensé que ça ne servait à rien, entre ceux qui te pondent un CdC sans avoir ne serais-ce que rencontré les utilisateurs finaux et ceux qui cherche à t'expliquer ton métier...jusqu'au jour ou j'ai rencontré THE chef de projet, cette jeune femme, quand elle rédigeait un CdC c'était pas compliqué, non seulement il répondait à l'attente (exprimée) des utilisateurs, mais il répondait à toutes les questions que je pouvais me poser durant le développement, un régal. Avec un tel chef de projet, la seule connaissance de la technique est suffisant.
    Developpez.com: Mes articles, forum FlashPascal
    Entreprise: Execute SARL
    Le Store Excute Store

  3. #3
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 044
    Points
    32 044
    Par défaut
    Foutaises, foutaises et foutaises.

    Foutaises d'abord, parcque des codes ignobles, il y en a toujours eu. "GOTO considered harmful", ça a plus de 40 ans. J'ai refondu du code de 1972 absolument atroce. Et des utilisateurs finaux qui bricolent un code illisible - mais qui les dépanne bien - ça ne date pas d'hier(VBA pour EXCEL, c'est le début des années 1990, par exemple, et il y avait des précurseurs)

    Foutaises ensuite, parcequ'une bonne planification n'est pas une garantie, ni même une condition nécéssaire pour écrire du bon code. C'est certes un plus, mais les ça s'arrête là. La principale limite vient du fait que le monde change, donc les exogences changent aussi, souvent en cours de projet. Un code qui reste propre, c'est un code qui a su s'adapter aux changements d'exigences en cours de projet - sans devenir un truc horrible. Souvent, ça exige de repenser l'architecture.

    Foutaises enfin, parceque les mathématiques et la formalisation, ça a déjà été essayé à maintes reprises. Ca ne marche pas. Alistair Cockburn :
    Citation Envoyé par alistair Cockburn
    In the formal development of communications software, in 1987, I was given the motivation, “The problem with software development is that there is too much ambiguity in the problem statement and in the design description. Things will go better if we get people to work with mathematical formalisms.” After some work in this area, I discovered:

    ■Problem 1. The people on the projects were not interested in learning our system.
    ■Problem 2. They were successfully able to ignore us, and were still delivering software, anyway.
    Et en plus, ça coute une débauche d'energie démente pour des résultats limités. Joel Spolsky
    Citation Envoyé par joel Spolsky
    I read every word about Dynamic Logic that I could find in Becton, and I struggled with the problem late into the night. I was getting absolutely nowhere, and increasingly despairing of theoretical computer science. It occurred to me that when you have a proof that goes on for pages and pages, it’s far more likely to contain errors in the proof as our own intuition about the trivial statements that it’s trying to prove, and I decided that this Dynamic Logic stuff was really not a fruitful way of proving things about actual, interesting computer programs, because you’re more likely to make a mistake in the proof than you are to make a mistake in your own intuition about what the program “f := not f” is going to do.
    Sans aller aussi loin que lui, on peut constater que la logique formelle est juste utilisée dans des domaines hyper-spécifiques, comme l'aérospatial, et que ça coute des quantités astronomiques de jours-hommes pour prouver qu'un programme relativement simple marche comme prévu(encore faut-il ne pas s'être gourré dans la planification). Ca n'a aucun effet sur la lisibilité du code. Et surtout, c'est beaucoup trop cher pour la plupart des usages.

    Quand on me demande d'écrire un programme listant les clients à contacter par le marketing, ou mappant un quelconque flux sous un autre format, ou extrayant de la base de données les données nécéssaires à la facturation, j'ai le choix entre :
    (1)Coder comme un crétin sans réfléchir.
    (2)Faire marcher mon intuition, tracer quelques schémas rapidement, coder, et adapter les schémas si je m'aperçoit que je fais fausse route.
    (3)Passer deux ans à prévoir tout dans les moindres détails, avec des formalismes mathématiques irréprochables...Et tout jeter à la fin parceque j'ai oublié un détail, ou que le besoin a changé.

    Le bloggueur nous demande de choisir entre (1) et (3). Seul (2) nécéssite un peu de talent. (3) n'a de sens que si vous avez des moyens astronautiques. (1) est à éviter systématiquement(c'est le seul point sur lequel je suis d'accord avec lui). Et surtout, mon expérience, c'est que la hiérarchie, parfois nous demande (1) "on a pas commençé, on a déjà 3 semaines de retard!!!", parfois nous demande (3) "bon, tu vas nous spécifier tout ça au poil près". Jamais (2). C'est à nous, professionels, de savoir faire le niveau de planification adéquat, assez marqué pour savoir à peu près ou on va, mais assez léger pour que les inévitables corrections ne soient pas impossibles face à une architecture trop lourde.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  4. #4
    Expert éminent
    Avatar de pmithrandir
    Homme Profil pro
    Responsable d'équipe développement
    Inscrit en
    Mai 2004
    Messages
    2 418
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Responsable d'équipe développement
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2004
    Messages : 2 418
    Points : 7 295
    Points
    7 295
    Par défaut
    Comme toujours, le problème réside dans les avis tranchés.

    Je n'ai jamais vu un projet avec des spec écrite de bout en bout qui tenait le coup.
    Je n'ai jamais vu un projet sans spec tenir le coup.

    C'est pour cela qu'en général, sur un projet de 6 mois, on décide d'analyser les besoins principaux, qu'on met en place un schéma de données assez ouvert qui tient la route, et qu'en suite on créé une structure de code que l'on a souvent réfléchi sur papier / tableau blanc pour prendre un peu de recul.
    Si on bosse par sprint de 2 semaines, il n'est pas rare de demander a rassembler les 2 ou 3 premiers sprint pour faire un socle minimal histoire d'avoir une vraie base de discussion.

    Cette concentration sur la structure et les données dés le début nous évite souvent d'avoir un assemblage de bricolage comme on en trouve dans beaucoup de projet agile trop intégriste. (et ca permet de réfléchir notre stockage de donnée, la partie la plus importante du programme a tête reposée)

  5. #5
    Modérateur
    Avatar de Rayek
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Mars 2005
    Messages
    5 235
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2005
    Messages : 5 235
    Points : 8 504
    Points
    8 504
    Par défaut
    Il oublie fortement de parler des deadlines qui sont de plus en plus courte et qui ne permettent pas de faire un code propre
    Modérateur Delphi

    Le guide du bon forumeur :
    __________
    Rayek World : Youtube Facebook

  6. #6
    dk
    dk est déconnecté
    Membre actif
    Profil pro
    Inscrit en
    Juin 2004
    Messages
    75
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2004
    Messages : 75
    Points : 238
    Points
    238
    Par défaut
    Je suis assez d'accord avec lui. Les deux raisons majeures selon moi sont que :
    • la majorités des développeurs sont avant tout des fonctionnels avant d'être des techniciens, tant que ça fonctionne ils s'en foutent royalement de la réalisation (et encore plus de la conception). Donc peu importe la méthode, la majorité des développeurs s'en moque et bâclera le travail.
    • le client sous estime toujours le coût d'une application, les délais permettent juste de faire (et encore...), mais rarement de bien faire.

    Cela crée donc un cercle vicieux qui aboutit systématiquement à une qualité de code/conception minable.

  7. #7
    Membre confirmé Avatar de CHbox
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Août 2011
    Messages
    107
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2011
    Messages : 107
    Points : 540
    Points
    540
    Par défaut
    Comme dans beaucoup trop de domaines, les anciens se focalisent sur ce qui va mal dans le nouveau et occultent ce qui allait mal à leur époque (les jeux vidéos, la musique, la culture, la politique, la société, tout en fait), comme dit plus haut des mauvais dev il y en a toujours eu mais on les a oublié forcément, et des bons devs il y en a beaucoup de nos jours, c'est juste la proportion qui a changée dû à la démocratisation du secteur, il faut arrêter de se mettre des œillères et de généraliser avec.

  8. #8
    Membre éprouvé
    Profil pro
    Développeur .NET
    Inscrit en
    Février 2005
    Messages
    363
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2005
    Messages : 363
    Points : 1 034
    Points
    1 034
    Par défaut
    On a plus de code correcte par ce que les temps prévu pour le dev sont tellement devenu cours et que les appli deviennent de plus en plus complexes.

    Mais c'est vrai qu'on décrit dans les grandes lignes ce que dois faire une application mais dans le détail c'est plus rare.


    De toute manière, on dev des apps qui sont buggées et le client dois payer pour corriger les bugs. Ca fait partie des business plan actuelles.

    Je vois mal un client attendre pour avoir un truc bien peaufiné.

  9. #9
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    Novembre 2012
    Messages
    3 375
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2012
    Messages : 3 375
    Points : 9 944
    Points
    9 944
    Par défaut
    Une étude a montré que 100% des cheveux gris pensent que "de leur temps, c'était mieux".
    One Web to rule them all

  10. #10
    Membre expert Avatar de Kearz
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mai 2012
    Messages
    856
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Nord (Nord Pas de Calais)

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

    Informations forums :
    Inscription : Mai 2012
    Messages : 856
    Points : 3 659
    Points
    3 659
    Par défaut
    L’éternel débat et de toute façon c'était mieux avant: le code source, c'était mieux avant. Et en plus avant on avait pas peur du travail à abattre! *Ahem*

    Plus sérieusement, ça dépend dans les langages mais oui, certains codes sont affreux. Je prends l'exemple du web, pour faire du web il faut de plus en plus de langage mais il faut un minimum de développeur.
    Quand tu fais seul: le PHP, le code d'un Template X ou Y, JS (mais avec Jquery + Modernizr), HTML5/CSS3 (mais attention full responsive!), SQL...Ben ça commence à faire beaucoup. Donc faire du code propre dans tous ses langages c'est compliqué.
    Maintenant c'est vrai dans tous les langages moderne ou presque. C'est vrai que j'avais fait un stage dans un monde "assez vieux" avec du AS400 et uniquement de RPG, le code semblait plutôt propre, c'est normal avec un et uniquement langage.

    Maintenant, je suis pas sur que les codes étaient plus propre avant. Sans les IDEs par exemple les codes non/mal indenté devaient être illisible.

  11. #11
    Membre régulier
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    Juillet 2011
    Messages
    30
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Industrie

    Informations forums :
    Inscription : Juillet 2011
    Messages : 30
    Points : 111
    Points
    111
    Par défaut
    Une fois, j'ai eu l'occasion de bosser avec IT manager, un "vieux de la vieille" de l'informatique mélangé avec maître Yoda, il avait un poster dans son bureau qui listait les principes à toujours garder à l'esprit pour mener à bien un projet. Avec le temps, je me suis rendu compte qu'il avait toujours raison. Voici ces principes:

    1-Aucun grand projet informatique n'est jamais mis en place dans les délais, dans les limites du budget, avec le même personnel qu'au départ et le projet ne fait pas ce qu'il est censé faire non plus. Il est fort improbable que le vôtre soit le premier.
    -Les bénéfices seront inférieurs aux estimations, si on a pensé à faire des estimations.
    -Le système finalement mis en place le sera avec du retard, et ne fera pas ce qu'il est censé faire.
    -Il coûtera plus cher mais ce sera une réussite technique.

    2-L'un des avantages à fixer des objectifs vagues, c'est que vous n'aurez pas de difficultés à estimer les dépenses correspondantes.

    3-L'effort nécessaire pour redresser le cap croit géométriquement avec le temps
    -Plus vous attendez pour définir les objectifs, plus c'est difficile
    -Après l'installation, c'est trop tard.
    -Faites le maintenant

    4-Les buts, tels que les entend celui qui en décide, seront compris différemment par chacun des autres.
    -Si vous vous exprimez avec une clarté telle qu'il soit impossible que qui que ce soit ait mal compris, ce sera quand même le cas de quelqu'un.
    -Si vous faites quelque chose qui, vous en êtes sur, recevra l'approbation de tous, quelqu'un n'aimera pas ça.

    5-Seuls les bénéfices mesurables sont réels. Or, les bénéfices immatériels ne sont pas mesurables. Donc les bénéfices immatériels ne sont pas réels.

    6-Toute personne qui peut travailler à temps partiel pour un projet n'a surement pas assez de travail en ce moment.
    -Si son patron ne lui donne pas un travail à temps complet, vous ne devez pas le faire non plus.
    -S'il y a un problème de répartition d'horaires, le travail de son patron n'en souffrira pas.

    7-Plus grande est la complexité technique du projet, moins vous avez besoin d'un technicien pour le diriger.
    -Trouvez le meilleur manager possible, il trouvera le technicien.
    -Le contraire n'est presque jamais vrai

    8-Un projet mal planifié prendra 3 fois plus de temps à réaliser que prévu.Un projet bien planifié prendra seulement 2 fois plus de temps.

    9-S'il y a un risque que quelque chose marche mal, ça marchera mal. S'il est impossible que quelque chose marche mal, ça marchera mal quand même

    10-Quand les choses vont bien, quelque chose ira mal
    -Quand les choses ne peuvent réellement pas devenir pire, elles le deviendront
    -Quand les choses semblent aller mieux, c'est que vous avez oublié quelque chose

    11-Les équipes de projet détestent les compte-rendus hebdomadaires d'avancement des travaux parce que ceux-ci mettent trop vivement en lumière l'absence de leur progrès

    12-Les projets progressent rapidement jusqu'à 90% de leur achèvement, puis ils restent achevés à 90% pour toujours

    13-Si on laisse le contenu d'un projet changer librement, le taux de changement dépassera le taux d'avancement.

    Je pense qu'il n'y a pas grand'chose à ajouter

  12. #12
    Membre émérite

    Profil pro
    Inscrit en
    Décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 995
    Points : 2 528
    Points
    2 528
    Par défaut
    J'ai aussi l'impression qu'il y a une dégradation de la situation. Les facteurs sont nombreux. La démocratisation de la programmation, les deadlines de plus en plus courtes, du code pourri qui n'est jamais mis à la poubelle, etc.

  13. #13
    Membre régulier
    Homme Profil pro
    Formateur en informatique
    Inscrit en
    Mars 2008
    Messages
    24
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Formateur en informatique

    Informations forums :
    Inscription : Mars 2008
    Messages : 24
    Points : 71
    Points
    71
    Par défaut
    Je partage ce qui vient d'être dit.
    Depuis plusieurs années, mon expérience de chef de projet montre que les raisons principales pour lesquelles on arrive pas à tenir nos échéances sont :
    - une analyse fonctionnelle trop succincte --> certains choix fonctionnels faits en cours de dev nécessitent beaucoup de refacto de code
    - une analyse technique trop succincte --> si on s'aperçoit au milieu du dev que telle ou telle contrainte (ex : volume de données, performance...) n'a pas été prise en compte au départ, ça peut remettre en cause une partie du code déjà écrit.
    - ajouter des choses sur du code ancien mal architecturé et incompréhensible

    Sur des applis complexes, la phase d'architecture technique est absolument indispensable et je pense que c'est le sens principal des propos de Leslie Lamport.
    Plus on anticipe les choses, plus on est en mesure de faire du code propre, maintenable et évolutif. Ensuite, bien entendu le développeur doit avoir à coeur de faire du travail de qualité...

  14. #14
    Membre expérimenté Avatar de Uranne-jimmy
    Homme Profil pro
    Bioinformatique
    Inscrit en
    Décembre 2012
    Messages
    778
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Bioinformatique
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : Décembre 2012
    Messages : 778
    Points : 1 461
    Points
    1 461
    Par défaut
    Comme partout, être autodidacte a plusieurs signification. En programmation, deux choses sont importantes à apprendre : la grammaire, et la méthode. Aussi bien la grammaire, la partie construction, donc, est facile à apprendre, elle nécessite d'intégrer des principes, de connaitre les règles. Aussi bien la méthode est généralement plus difficile à obtenir, sur internet on trouve beaucoup moins de source.
    J'ai été autodidacte par simple envie pendant quelques années, avant de spécialiser mes études en ajoutant la compétence programmation, et malgré la pauvreté de l'enseignement (la licence pro bioinfo carcassonne, n'y allez pas), avoir un prof qui nous apprends plus que le code la manière, ça a booster mes capacités. Et à plus grande ampleur, developpez.net m'a apporté beaucoup dans la méthode.

    Je résume mes propos médulleux (^^') : ce n'est pas qu'on oublie une étape, c'est qu'on apprend pas a réfléchir.

    Mais comme disent beaucoup ici, il n'y a pas proportionnellement plus de mauvais qu'avant, bien que je pense que ce soit lié à la souplesse grandissante des langages.
    Expert en recherche google caféinomane

  15. #15
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par dk Voir le message
    la majorités des développeurs sont avant tout des fonctionnels avant d'être des techniciens, tant que ça fonctionne ils s'en foutent royalement de la réalisation (et encore plus de la conception). Donc peu importe la méthode, la majorité des développeurs s'en moque et bâclera le travail.
    Pire les techniques parlent une autre langue ( vu que le reste des intervenants ne les comprend jamais à plus de 50% ) leurs mises en garde et leurs idées concrètes ont du mal à être mises en œuvre.

    Citation Envoyé par Cedric Chevalier Voir le message
    Cependant, alors que la logique voudrait aussi que la qualité du code s’améliore avec le temps, c’est l’inverse qui se produit. Qu'est-ce qui peut expliquer ce phénomène ?
    Le manque de temps et la dilution des compétences...

    Citation Envoyé par Cedric Chevalier
    Pour étayer ses propos, l’expert a fait une analogie avec le domaine de l’architecture. Un architecte fait toujours un plan détaillé d’une bâtisse avant sa réalisation sur le terrain. Certes, même si ce plan ne garantit pas à 100% la solidité de l’édifice, l’architecte ne peut s’en passer, tout simplement parce que sans lui, il obtiendrait de très mauvais résultats. Pourquoi pas le programmeur ?
    J'ai vu un reportage où un chinois faisait construire une pagode sans plan mais il connaissait la taille de chaque pièce et sa position final exacte !!!

    Citation Envoyé par Cedric Chevalier
    À la différence de l’architecte, le programmeur ne fait pas de plan, mais doit réaliser des spécifications logicielles avant de se lancer dans la phase du code. Sauf qu’en pratique, ce n’est pas le cas.
    C'est la spécialisation des rôles l'architecte fait des plans le maçon monte le mur, pareil en informatique c'est l'ordre des choses de nos jours.

    Citation Envoyé par Cedric Chevalier
    Alors, comment écrire de bonnes spécifications logicielles ? Il n’existe pas de règle absolue d’après l’expert.
    Verbiage !

    Citation Envoyé par Cedric Chevalier
    Cependant, il pense que la mathématique serait d’un apport appréciable avec des notions comme les ensembles, les fonctions et la logique.
    Si notre expert avait fait des maths et pas seulement la première année de fac, il aurait été confronté à de vrais problèmes de modélisation et n'inventerait pas des remèdes digne de la poudre de perlimpinpin

    Les trois cités ci-dessus ne sont que des fondements qui n'intéressent que les experts en mathématiques et qui permettent à d'autres d'écrire des théories utilisables mais réduite à un domaine.

    Citation Envoyé par Cedric Chevalier
    Êtes-vous d'accord avec l'expert ?
    marre des experts à la noix

  16. #16
    Membre averti

    Profil pro
    Inscrit en
    Juin 2013
    Messages
    114
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2013
    Messages : 114
    Points : 327
    Points
    327
    Billets dans le blog
    3
    Par défaut
    Citation Envoyé par valkirys Voir le message
    Si notre expert avait fait des maths et pas seulement la première année de fac, il aurait été confronté à de vrais problèmes de modélisation et n'inventerait pas des remèdes digne de la poudre de perlimpinpin
    L'expert en question est mathématicien de formation, passé par le MIT, puis Brandeis où il a eu un PhD sur les équations différentielles aux dérivées partielles. En dehors du prix Turing, il a eu quelques distinctions un peu pointues. Quand il parle de maths, il sait plutôt de quoi il parle. Il est aussi l'auteur de quelques programmes assez largement répandus, donc il connait un peu la programmation...

    Bref, il est allé un peu plus loin que la première année de fac. Et je crois que ça explique une partie de ses commentaires. A sa génération, on avait relativement peu de programmeurs, mais parmi eux, il y avait beaucoup de gens avec un niveau scientifique TRES élevé (en maths, en physique, en stats). Depuis, l'informatique s'est beaucoup démocratisée, et le programmeur est devenu un ouvrier spécialisé, avec un niveau de maths souvent plus faible, mais moins d'initiative. Et pour l'encadrer, on a vu apparaitre tout une catégorie de chefs de projets et autres architectes, mieux formés, mais ayant souvent une expérience TRES limitée de la programmation.

    Bref, on est passé d'une informatique relativement artisanale, et surtout très pointue, à une activité de masse, plus industrielle, avec des OS, des contremaitres et des ingénieurs. Du coup, la nature du produit fini (le code) a changé, et avec elle les "bonnes pratiques", et c'est assez normal.

    Francois

  17. #17
    Membre confirmé Avatar de KsassPeuk
    Homme Profil pro
    Ingénieur Chercheur
    Inscrit en
    Juillet 2013
    Messages
    138
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur Chercheur
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2013
    Messages : 138
    Points : 635
    Points
    635
    Par défaut
    Citation Envoyé par valkirys Voir le message
    Les trois cités ci-dessus ne sont que des fondements qui n'intéressent que les experts en mathématiques et qui permettent à d'autres d'écrire des théories utilisables mais réduite à un domaine.
    Ouais d'ailleurs la recherche en informatique fondamentale, ça n'apporte absolument rien. Puis les méthodes formelles, ça ne fonctionne nulle part. Tsss ...
    Sur tous les systèmes relativement bas-niveaux, on peut spécifier et prouver des propriétés qui peuvent être assez complexes si on s'en donne la peine. On pourrait s'en servir ... je sais pas .. heu pour prouver qu'on n'a pas de buffer-overflow qui traîne dans l'implémentation d'un protocole de dialogue sécurisé ? Peut être que c'est un usage pertinent ?

    Citation Envoyé par valkirys Voir le message
    marre des experts à la noix
    Autant je suis pas d'accord avec un certain nombre d'idée de L.Lamport. Autant, annoncer de but en blanc "Lamport est un expert à la noix", je trouve qu'il faut pas avoir froid aux yeux. Quand on voit tout ce qu'il a fait juste dans le domaine de la programmation concurrente et les algo lock-free/non-blocking (tient un domaine où tester est impossible), lui cracher au visage est juste ultra-déplacé (à moins éventuellement que toi aussi tu aies reçu un prix Turing ?).

  18. #18
    Expert confirmé
    Avatar de TiranusKBX
    Homme Profil pro
    Développeur C, C++, C#, Python, PHP, HTML, JS, Laravel, Vue.js
    Inscrit en
    Avril 2013
    Messages
    1 476
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur C, C++, C#, Python, PHP, HTML, JS, Laravel, Vue.js
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2013
    Messages : 1 476
    Points : 4 805
    Points
    4 805
    Billets dans le blog
    6
    Par défaut
    Evidemment que le code est de moins en moins bon avec ces Nom : censurerim.gif
Affichages : 937
Taille : 1,4 Ko de deadlines trop courtes et sans marges de manœuvres
    du coup pour tenir les délais on écris à l’arrache et ça donne du code pourris
    Rien, je n'ai plus rien de pertinent à ajouter

  19. #19
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par fcharton2 Voir le message
    L'expert en question est mathématicien de formation, passé par le MIT, puis Brandeis où il a eu un PhD sur les équations différentielles aux dérivées partielles. En dehors du prix Turing, il a eu quelques distinctions un peu pointues. Quand il parle de maths, il sait plutôt de quoi il parle. Il est aussi l'auteur de quelques programmes assez largement répandus, donc il connait un peu la programmation...

    Bref, il est allé un peu plus loin que la première année de fac. Et je crois que ça explique une partie de ses commentaires.
    Super ! Alors pourquoi réduire l'amélioration des projets informatiques à de la logique, des ensembles, les fonctions ?

    On sait bien que ces notions fondamentales ont été portées aux nues, qu'elles sont utiles ( comme formations scolaires et dans leurs usages ) mais en aucun cas une solution miracle, même pas un début de solution...

    Citation Envoyé par KsassPeuk Voir le message
    Ouais d'ailleurs la recherche en informatique fondamentale, ça n'apporte absolument rien. Puis les méthodes formelles, ça ne fonctionne nulle part. Tsss ...
    Sur tous les systèmes relativement bas-niveaux, on peut spécifier et prouver des propriétés qui peuvent être assez complexes si on s'en donne la peine. On pourrait s'en servir ... je sais pas .. heu pour prouver qu'on n'a pas de buffer-overflow qui traîne dans l'implémentation d'un protocole de dialogue sécurisé ? Peut être que c'est un usage pertinent ?
    Cela ne concerne pas grand monde ( en proportion ), pour le "génie logiciel" comme on disait, je ne suis peut-être plus à la page, mais ils ont d'autres problèmes dans la réalisation de leur logiciel que les fondements de la logique !!!
    Les specs et la communication pour commencer...

    Si on prend l'exemple de frama c ( il me passe par la tête ), qu'elle est le pourcentage d'utilisation?
    De bonne utilisation?
    Et ici combien connaisse la théorie de Galois utilisé pour créer ce soft?

    On est loin de l'usage général.

    Citation Envoyé par KsassPeuk Voir le message
    Autant je suis pas d'accord avec un certain nombre d'idée de L.Lamport. Autant, annoncer de but en blanc "Lamport est un expert à la noix", je trouve qu'il faut pas avoir froid aux yeux. Quand on voit tout ce qu'il a fait juste dans le domaine de la programmation concurrente et les algo lock-free/non-blocking (tient un domaine où tester est impossible), lui cracher au visage est juste ultra-déplacé (à moins éventuellement que toi aussi tu aies reçu un prix Turing ?).
    Certes, mais je ne le visais pas en particulier et je ne crache pas au visage des gens ni au propre ni au figuré.

    Cela dit, il y a deux problèmes l'usage du mot expert pour imposer une idée ou une forme de pensée, et le fait que ces génies dans leur domaine s'amusent hors de leur connaissance habituelle...

    Comment peut-on être crédible en soutenant que des connaissances basiques feront de miracles?


    PS :
    voir la table des matières de http://www.amazon.fr/Concrete-Mathem.../dp/0201558025
    de Donald Knuth, pas de théorie des ensembles ni logique...

    Comme je l'ai dit, je sais que c'est utile mais la théorie des graphes l'est aussi et plusieurs autres ( la géométrie dans certain cas ), les propos de Leslie Lamport sonne comme un vilain écho des "math modernes" des années 70 pas adaptés de nos jours.
    Dernière modification par Invité ; 10/04/2014 à 16h22.

  20. #20
    Membre confirmé Avatar de KsassPeuk
    Homme Profil pro
    Ingénieur Chercheur
    Inscrit en
    Juillet 2013
    Messages
    138
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur Chercheur
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2013
    Messages : 138
    Points : 635
    Points
    635
    Par défaut
    Citation Envoyé par valkirys Voir le message
    (1)
    Si on prend l'exemple de frama c ( il me passe par la tête ), qu'elle est le pourcentage d'utilisation?
    De bonne utilisation?
    On est loin de l'usage général.

    (2)
    Et ici combien connaisse la théorie de Galois utilisé pour créer ce soft?
    (1) Cela se développe progressivement, auprès d'entreprises qui ont besoin d'un niveau de fiabilité critique. Evidemment, dans une certaine mesure, ça ne touche pas tout le monde. Mais peut être que se bouger pour apporter cette garantie pour les parties basses de nos systèmes d'exploitation serait une bonne chose (je vais revenir dessus plus loin), ou encore les interfaces/protocoles de dialogue (SSL et compagnie ...), et ça ça touche tout le monde.
    D'autre part, je trouve que l'idée de "ce n'est pas beaucoup utilisé, ne l'utilisons pas" est un bel exemple de frein à l'innovation.

    (2) Le but quand on fournit des outils c'est qu'on ait pas besoin de comprendre comment il fonctionne. Ne pas comprendre comment fonctionne l'outil n'empêche pas de formaliser.

    Citation Envoyé par valkirys Voir le message
    Comment peut-on être crédible en soutenant que des connaissances basiques feront de miracles?
    Parce que c'est déjà utilisé avec succès : avec des travaux comme seL4, ou microsoft qui bosse sur Midori, ou CompCert. Et parce qu'il y a des domaines où tu peux faire tous les tests que tu veux, tu n'arriveras pas à vérifier quoique ce soit : les programmes concurrents c'est ce vers quoi on doit tendre pour continuer à augmenter nos performances mais c'est simplement pas testable.
    Evidemment qu'on ne peut pas encore tout faire, mais si on n'essaye pas effectivement, ça ne risque pas d'avancer. Plus on disperse ce type de connaissance plus on est capable de réduire le nombre de chose à savoir pour les utiliser. Il y a des années pour programmer fallait être une tête de la mort qui tue, aujourd'hui ce n'est plus le cas. Pourquoi ça ne pourrait pas marcher de la même manière pour la formalisation ?

Discussions similaires

  1. La qualité du code a-t-elle foutu le camp chez les programmeurs ?
    Par Cedric Chevalier dans le forum Actualités
    Réponses: 72
    Dernier message: 29/04/2014, 12h51
  2. Code ok sur mon PC mais pas chez les autres ?
    Par catherineFR27 dans le forum Général VBA
    Réponses: 6
    Dernier message: 04/06/2007, 21h29
  3. [Visual Web] visual web et qualité du code
    Par robert_trudel dans le forum NetBeans
    Réponses: 4
    Dernier message: 11/12/2006, 13h11
  4. qualité du code
    Par clementphp dans le forum Langage
    Réponses: 6
    Dernier message: 10/07/2006, 15h22

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