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

Le , par Cedric Chevalier, Expert éminent sénior
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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Paul TOTH 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.
Avatar de el_slapper 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.
Avatar de pmithrandir pmithrandir - Membre expert 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)
Avatar de Rayek 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
Avatar de dk dk - Membre actif https://www.developpez.com
le 10/04/2014 à 11:35
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.
Avatar de CHbox CHbox - Membre confirmé https://www.developpez.com
le 10/04/2014 à 11:50
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.
Avatar de xarkam xarkam - Membre averti https://www.developpez.com
le 10/04/2014 à 12:06
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é.
Avatar de SylvainPV 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".
Avatar de Kearz Kearz - Membre expert https://www.developpez.com
le 10/04/2014 à 12:21
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.
Avatar de ustensile 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
Offres d'emploi IT
Responsable transverse - engagement métiers H/F
Safran - Ile de France - Corbeil-Essonnes (91100)
Consultant sap finance/controlling H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)
Ingénieur intégration, validation, qualification du système de drone H/F
Safran - Ile de France - Éragny (95610)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil