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 !

La qualité du code a-t-elle disparu chez les programmeurs ?
Un expert s'exprime sur la question

Le , par Cedric Chevalier

0PARTAGES

7  3 
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 ?

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

Avatar de Rayek
Modérateur https://www.developpez.com
Le 10/04/2014 à 10:32
Il oublie fortement de parler des deadlines qui sont de plus en plus courte et qui ne permettent pas de faire un code propre
21  0 
Avatar de Paul TOTH
Expert éminent sénior https://www.developpez.com
Le 10/04/2014 à 5:10
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.
19  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 10/04/2014 à 9:36
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.
17  2 
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 10/04/2014 à 12:12
Une étude a montré que 100% des cheveux gris pensent que "de leur temps, c'était mieux".
12  0 
Avatar de fcharton2
Membre averti https://www.developpez.com
Le 10/04/2014 à 14:26
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
11  0 
Avatar de pmithrandir
Expert confirmé https://www.developpez.com
Le 10/04/2014 à 9:53
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)
9  0 
Avatar de coolspot
Membre confirmé https://www.developpez.com
Le 10/04/2014 à 15:59
En même temps c'est pas étonnant vu que les SSII ont vampirisé le marché informatique et que leur dogme c'est produire le plus vite possible au plus bas cout possible tout en vendant le plus cher possible pour gratter un maximum de marge.

Ca donne des développeurs payés en cacahuète avec des délais de livraison intenable pour privilégier le cours terme. Et de toute façon si le code doit être revu ca fera l'objet d'une facturation ultérieur au client

Bref comme le dicton dit : When you pay peanuts, you'll get monkey.
9  0 
Avatar de ustensile
Membre régulier https://www.developpez.com
Le 10/04/2014 à 13:03
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
8  0 
Avatar de e-ric
Membre expert https://www.developpez.com
Le 16/04/2014 à 13:33
Citation Envoyé par Paul TOTH Voir le message
car dès fois on se demande tout de même si le bon code est recherché. C'est en tout cas l'impression que j'ai quand on me refuse un devis considéré comme trop cher et qu'on me demande si je ne connais pas un jeune qui débute qui voudrais se faire les dents sur le projet.
Et quand le projet va vraiment mal ou qu'il faut le maintenir ou encore parce qu'on se rend compte qu'un programme qui marche ça sert bien aussi, on appelle le pompier de service i.e. un bon développeur qui ramasse toutes les bouses de ses prédécesseurs. Il règne dans le monde de l'informatique, en particulier de gestion, une philosophie selon laquelle la programmation est en quelque sorte du boulot de saisie, sans grande qualification, et que seule la conception prime d'où l'importance accrue des CDP et de la MOA au détriment des développeurs. Ces derniers sont généralement considérés comme des petites mains.

Le problème est que l'un ne va pas sans l'autre une super conception sans une bonne réalisation ne vaut pas plus qu'une réalisation qui tente de compenser une conception ratée. Une absence de conception est parfois préférable car il laisse le champ libre pour un développeur qui connaît son boulot.

la complexification croissante des EDI qui en apportant du confort à des développeurs confirmés ne sont plus à la portée du premier venu. Il n y a qu'à comparer les EDI actuels et celui de TurboPascal 4.0.

Pour rigoler, chez un client, les développeurs micro étaient classés bureauticiens, tout un symbole.
7  0 
Avatar de Simara1170
Membre éprouvé https://www.developpez.com
Le 28/04/2014 à 11:12
J'entends parler de théorèmes de maths complexes, et je dois avouer que quelque part, ça me bloque...
J'ai un "bête" DUT en informatique (spécialité Génie Logiciel), que j'ai validé avec quelque chose comme 3 en maths (je suis vraiment une brêle en math...), mais par contre j'ai avoiné avec 17-18 de moyenne en logique et en algo... Et je m'en sors très bien.
Je ferais jamais de logiciel "haut niveau" comme de l'IA ou quoi que ce soit, et je considère d'ailleurs que les mecs qui font ça, sont purement des génies...

Bref, ma conception du métier et que le mathématicien, et le dév' sont deux entités séparées: l'un modélise le modèle mathématique à utiliser, et l'autre l'implémente de manière à ce que la machine le comprenne...

Ca c'était la digression sur l'emploi des maths en informatique, que je trouve moins importantes que la logique pure et dure (je peux me tromper, j'suis pas non plus un vieux briscard ).

Pour en revenir à la qualité de code, je dirais que le soucis, c'est la société de consommation: toujours plus vite, toujours moins cher... Et ça marche pas... C'est comme si on demander à un entrepreneur de construire un building en 1 mois au lieu d'un an... On aurait quoi comme problème? une dalle et des fondations fendues parce qu'on aurait construit dessus, avant que le béton soit sec, et des murs pas droit, parce que pas le temps de les monter au niveau et au fil à plomb? C'est ubuesque...

Je travaille pour une école, et je démine le code pissé par un autodidacte de 55 ans maintenant... Et quand je vois ça, j'me dit que les dév' ou auto-proclammé dev' de la génération d'avant codait pas mieux que ceux de maintenant, c'est juste qu'on passait l'éponge pour une technologie naissante et à ses balbutiements... Mais la société juge qu'en 20 ans on connaît tout de l'informatique et qu'il ne devrait plus y avoir d'erreur...

Je bosse sur un code spaghetti avec des pansements et des rustines sur les pansements, la faute à quoi? Il sais pas coder? Non, il y a des bouts de codes très élégants pour certaines tâches. La faute en revient au manque de modélisation, qui existait il y a 30 ans quand des autodidactes bricolait leur truc dans leur coin, et qui existe maintenant par "faute de temps".
Je me rappelle un adage de mon prof de programmation système qui disais: "le premier outil d'un informaticien, c'est un crayon et une feuille"
Si t'a pas couché sur le papier tout ce que le programme et censé faire, tu va droit dans le mur:

Tu penses que ton programme est un cheval, alors tu programmes un cheval. puis on vient te dire que c'est un cheval de course, alors tu l'affines et tu lui fait des jambes plus longues, ensuite on te dit que ça serais plus joli avec une corne, alors t'en colles par dessus. et enfin on te dit, ça serait bien s'il volait mon cheval, et donc tu lui greffes des ailes...

Ca si c'est spécifié dès le début, t'a une licorne volante...Si c'est pas spécifié on obtient un mulet à grande jambes avec une corne à la place de la queue et des ailes ridiculement petite à la place des oreilles...
Je capilotracte le truc, mais l'essentiel et là: le code est mauvais parce que la spécif' est mauvaise, et quand la spécif' est bonne, les architectes et les dev' se comprennent pas, ou veulent pas parce que l'archi c'est un con qui y connaît rien (c'est parfois vrai) et que le dev' est un glandeur qui veut pas avancer assez vite... Il y aurais meilleure entente et compréhension entre les 2 corps de métier, je parie mon chapeau (que je n'ai pas ) que la qualité de code remonterait en flèche...

Si on ajoute à ça, le fait que le client est sensibilisé à la difficulté de la création, et comprend que ça ne se fasse pas d'un claquement de doigts, et on arriverait à mener des projets à bien sans tout les soucis qu'on peut rencontrer au niveau bug et spécif' foireuse...

Comme je travaille dans le SI d'une boîte, j'ai mes "clients" (les utilisateurs finaux en fait) sous la main. Alors je prends le temps de lui demander plusieurs fois ce qu'il veut, et je lui reformule, histoire d'être sûr d'être sur la même longueur d'onde.
Ensuite, je lui explique ce que je vais faire, et les écueils que je pourrait avoir sur le chemin (intégrité des données sur la DB, par exemple), soucis de compatibilité avec l'existant, et que donc j'aurais fait ça en X temps, sous réserve de ne pas tomber sur un autre problème, et dès que j'ai un nouveau souci, je lui en parle, en lui expliquant que ça me prendras X temps en plus... Résultat, le client est content (il voit que son problème est pris au sérieux) et moins à cheval sur des délais impossible puisqu'on lui détaille pourquoi ce délai. Et des fois, ils arrivent même à te proposer une solution viable à laquelle t'avais pas pensé...

Bref tout ça pour dire que s'il y avait plus de transparence pour le client, ça serait mieux aussi pour la qualité de code, mais les SSII préfèrent maintenir ses clients dans l'ignorance pour se faire du pognon en facturant des trucs immenses qui sont en fait une broutille corrigé dans la minute...
7  0