Pourquoi réécrire un projet en partant de zéro ? Parce que l'ancien code est un fatras ?

Pourquoi réécrire un projet en partant de zéro ? Parce que l'ancien code est un fatras ?
Ou parce qu'il est plus facile d'écrire que de lire un code ?

Pour un nouveau projet, certains développeurs préfèrent exploiter un code existant et l'adapter à de nouvelles fonctionnalités. D'autres par contre peuvent décider de partir de rien alors qu'il y a un code existant. Mais Joel Spolsky, un développeur de logiciels à New York, estime qu'écrire un programme à partir de zéro est la pire erreur stratégique qu'un développeur puisse commettre.

Dans l'espoir de mieux se faire comprendre, Joel avait énuméré plusieurs cas, dans un billet datant de l'année 2000. Entre autres, le navigateur de Netscape qui n'existe plus aujourd'hui. Netscape 6.0 allait entrer dans sa première version beta publique à l'époque en sautant la version 5.0. La version 4.0 fut sa dernière version majeure et avait été publiée trois ans plus tôt. Trois ans, c'est terriblement long dans le monde de l'Internet, déclarait Joel. « Pendant ce temps, Netscape était assis, impuissant, alors que sa part de marché s'effondrait », ajoutait-il. La cause, selon Joel, est que ses développeurs ont décidé de réécrire la base de code à partir de zéro.

Pièce jointe 373990

D'après Joel Spolsky, les développeurs sont, dans leur for intérieur, des architectes. Et la première chose qu'un architecte veut faire quand il arrive sur un site est de le raser complètement pour construire quelque chose de grandiose. Ils sont un peu hostiles à la rénovation progressive qui consiste entre autres à bricoler et améliorer l'existant.

Il y a une raison subtile pour laquelle les programmeurs veulent toujours jeter le code et recommencer. La raison en est qu'ils pensent que l'ancien code est un fatras. Ils ont probablement tort. La raison pour laquelle ils pensent que l'ancien code est un fatras est qu'il est plus difficile de lire le code que de l'écrire. C'est pourquoi la réutilisation du code devient si difficile.

L'idée que le nouveau code est meilleur que l'ancien est manifestement absurde, déclarait Joel. L'ancien code a été utilisé. Il a été testé. Beaucoup de bogues ont été trouvés et ils ont été corrigés. Il n'y a rien de mal à ça. Chacun de ces bogues a pris des semaines d'utilisation dans le monde réel avant d'être trouvé. Le programmeur a peut-être passé quelques jours à reproduire le bogue dans un laboratoire et afin de le corriger. Même s'il s'agit de beaucoup de bogues, le correctif peut être une ligne de code, ou même quelques caractères. Mais, il ne faut pas perdre de vu que beaucoup de temps et de travail sont allés dans cette ligne de code ou ces quelques caractères.

Quand vous jetez l'ancien code et recommencez à zéro, vous jetez toute cette connaissance, toutes ces corrections de bogues, des années de travail de programmation. Vous jetez votre leadership sur le marché. Vous donnez un cadeau de deux ou trois ans à vos concurrents. Vous gaspillez une quantité exorbitante d'argent en écrivant le code qui existe déjà.

Même des changements architecturaux assez importants peuvent être faits sans jeter le code. Aussi, un ancien code jugé inefficace peut devenir très efficace avec des améliorations. Pour Netscape, l'opinion publique semble être que l'ancienne base de code était vraiment mauvaise et lente. Néanmoins, cela fonctionnait très bien sur un grand nombre de systèmes informatiques réels, et n'affectait qu'une petite partie du projet, qu'il était possible d'optimiser sans être obligé de réécrire tout le code.

Pour clore ses propos, Joel dit qu'il « est important de se rappeler que, lorsqu'on part de zéro, il n'y a absolument aucune raison de croire que l'on va faire un meilleur travail que la première fois. Vous n'avez probablement pas la même équipe de programmation qui a travaillé sur la première version, donc vous n'avez « plus d'expérience ». Vous allez juste refaire la plupart des vieilles erreurs et introduire de nouveaux problèmes qui n'étaient pas dans la version originale ».

Source : Joel Spolsky

Et vous ?

:fleche: Qu'en pensez-vous ?
:fleche: Préférez-vous recommencer les projets en partant de rien plutôt que de faire évoluer un code existant ? Pourquoi ?
:fleche: Avez-vous déjà pris l'initiative de réécrire un projet en repartant à zéro ? Comment a été cette expérience ?

Voir aussi :

:fleche: Trolldi : une brève histoire totalement exacte des langages de programmation, qui est complètement inspirée de faits
:fleche: Quel est l'effet du langage de programmation sur la qualité du logiciel ? Une étude tente de clarifier la situation
:fleche: Quelques points clés sur la programmation défensive, destinée à assurer la fonction continue d'un logiciel dans des circonstances imprévues

En principe, dans une entreprise qui fonctionne normalement, ce ne sont pas les développeurs lambda qui devraient prendre la décision de réécrire un projet.
Cela se décide au minimum au niveau du chef de projet. Et même plutôt au dessus, au niveau d'une direction technique et de la direction générale, parce qu'un simple chef de projet n'a en général pas tous les éléments pour juger du risque qu'il fait courir à sa société.

Tous ses points sont valides, mais il ne faut pas non plus voir le code existant comme le graal et la perfection que l'on ne peut plus atteindre et tout nouveau code comme forcément moins bien.
Je pense qu'un code trop vieux, s'il n'a pas été pensé parfaitement - et plus le code est vieux moins il l'aura été imo -, le faire évoluer devient très difficile voire quasi impossible sans remanier et réarchitecturer un sacré chantier.
De plus ce remaniement aura le même genre d'effets : supprimer du vieux code, réécrire du nouveau, et les problèmes dont il parle peuvent tout autant arriver.
Sans compter qu'un tel chantier sera rarement accepté par les supérieurs, et donc ça finira par du hack ci et là pour corriger le nouveau bug - et quand ils s'accumulent, l'historique des corrections devient de plus en plus un frein à l'évolution..

J'ai voté "pas d'avis" car cela dépend de la tâche, du temps qui est accorder à la réaliser.
Faire confiance au code source si c'est juste modifier une partie du code source ou encore ajouter une "petite" fonctionnalité à un projet interne ou qui a fait l'objet de sous-traitance.
Vérifier les ajout "extérieur" en détail avant ou durant ou après en fonction du temps et charge de travail globale.

P.S. : mais comme je veux arrêter le DEV, c'est déjà une vision abandonnée de ma part...
P.S. 2 : modifier le code source ou remplacer du vieux code par du nouveau, cela dépend de la licence d'utilisation... L'algorithmique reste bien souvent, pas forcément les appels de méthodes et déclarations de class. A l'exception d'une mise à jour de fichier du même groupe d'auteurs extérieur au projet global je n'y toucherai pas...
P.S. 3 : L'usage d'un RAD comme WinDev 22 Express ou C++ Builder ou NetBeans est lui très souvent le choix que je fais pour partir de zéro. Sauf si le projet n'est pas aussi dense ou complexe que cela et qu'une application console/terminal avec ouverture du port réseau pour accéder à une base de données, dans ce cas, VisualStudio ou GCC...
P.S. 4 : Une application terminal/console avec une interface GUI accessible via un port quelconque et exploitant le protocole HTTP est plutôt intrigante à envisager, donc Eclipse...

Je pense que ça dépend de deux facteurs importants:
- la qualité de l'API de la codebase
- la techno utilisée et les alternatives

Une codebase bien structurée dès le début, avec une bonne API, sera simple a améliorer vu qu'il faudra modifier les implémentations, et pas l'architecture.
Ce sera donc juste du refactoring et de la correction de bug (d'ou l’intérêt de voir plus loin que le bout de son nez quand on pense a l'architecture au début).

Au niveau d'un changement de techno, je pense que ça peut en valoir la peine par contre.
Imaginons que l'application est basé a 90% sur une vielle techno, qui fait mal son boulot, et que le passage vers une nouvelle techno réduirait énormément
la codebase tout en la simplifiant... si les dev sont formés a cette nouvelle techno alors cela ne sera que bénéfique, si le projet est un projet a long terme.

Mais dans tous les cas, une ré-écriture de zéro est toujours très risquée, même si cela dépend beaucoup de la complexité de l'application a la base.
Personnellement, je suis plus partisan de gros refactorings, mais pas d'une ré-écriture complète d'un seul coup.
Entre chaque refactor au moins, on peut vérifier que l'application fonctionne toujours bien sur les points liés aux modifications, et cela est bien plus simple a
voir que si on devait tout refaire de zéro.

La reécriture s'impose souvent , car la fonction du logiciel est connu, mais le code source a pu être perdu dans le temps .

Cela arrive plus souvent que l'on pense.

Après la reécriture permet de valoriser la nouvelle équipe, il faut bien qu'elle apporte un plus par rapport à l'ancienne équipe. Comment justifier le ROI sur le redéveloppement si on apporte pas de bonnes raisons même si tenant par les cheveux comme on dit...

Hello,

Je pense qu'un certain nombre de critères impactent la décision, dont entre autres :
- l'ampleur du projet,
- la documentation technique et fonctionnelle existante,
- la situation du code (ancien/récent, avec des tests ou pas),
- réutilisation de certaines fonctionnalités ou pas,
- le temps imparti,
- la pérennisation de l'application à long terme (changement de techno par exemple)

A titre personnel, il m'est arrivé de réécrire des programmes de 30k lignes car trop de codes "spaghettis" et morts dont le résultat était totalement incertain en cas de modifications profondes. Par contre, certains modules étaient très bien écrits, et donc facilement réutilisables. Résultat ? un code allégé de 70% qui répondait aux besoins nouveaux et qui en plus prenait moins de place mémoire.
Dans certains cas restreints (en terme d'ampleur) j'ai totalement réécrit.
Enfin, dans d'autres cas, j'ai juste modifié quelques lignes de codes et surtout modifié les tables de paramétrage. Mais là, le code était quasi totalement paramétré, ce qui facilitait la chose.

Mais tout ça c'est du passé pour moi, je ne fais maintenant plus que tester le travail des développeurs :mouarf:

Je ne suis pas vraiment d'accord avec ce qui est dit dans la news sur le fait que "L'idée que le nouveau code est meilleur que l'ancien est manifestement absurde, déclarait Joel. L'ancien code a été utilisé. Il a été testé.".

Si on réécrit du code, ce n'est pas pour qu'il y ait moins de bugs, c'est pour le rendre plus évolutif, plus facile à maintenir. Un programme lorsqu'il est écrit, est concu pour arriver à un scope fonctionnel donné. Ensuite, lorsqu'on lui ajoute des fonctionnalités, sa conception originale peut révéler des limites. Il arrive aussi qu'a force de corrections, le code initialement propre, devient bordélique. Dans ces 2 cas, il arrive un point où il faut agir (Idéalement, même il faudrait agir au fur et à mesure, mais ce n'est pas toujours possible, pour des raisons de temps ou de vision incomplète).

Lorsqu'on en arrive à un point où il faut agir, la solution de réécrire de zéro est rarement bonne. Parfois elle est inévitable (notamment si on change de langage...), mais souvent il est préférable d'agir en plusieurs phases. La première est de séparer la code base en modules. Cette séparation permettra ensuite de traiter chaque module indépendamment. L'intérêt de cette approche est surtout de diminuer le volume de code à traiter en une fois. Réécrire tout un programme de 0 est souvent une tâche trop grosse et risquée. Traiter un module réduit le risque.

On pourrait se dire que ce serait encore mieux d'avoir cette approche dès le départ et parfois de nouvelles équipes critiquent le boulot de l'ancienne. Mais le fait est que le concepteur original du programme n'avait pas toutes les billes en mains, alors qu'une fois le logiciel écrit et stabilisé, il est plus simple de voir comment on aurait pu l'écrire différemment.

Salut,

Citation:

---

Envoyé par Joel Spolsky

Joel Spolsky [...] estime qu'écrire un programme à partir de zéro est la pire erreur stratégique qu'un développeur puisse commettre. [...] L'idée que le nouveau code est meilleur que l'ancien est manifestement absurde, déclarait Joel. [...] L'ancien code a été utilisé. Il a été testé. Beaucoup de bogues ont été trouvés et ils ont été corrigés. [...] Pour clore ses propos, Joel dit qu'il « est important de se rappeler que, lorsqu'on part de zéro, il n'y a absolument aucune raison de croire que l'on va faire un meilleur travail que la première fois.

---

Je renvoie les propos de M. Joel Spolsky à ce qu'a écrit un jour Thomas Edison : "Ce n'est pas en améliorant sans cesse la bougie qu'on a inventé l'ampoule"

Même si il est vrai que :

- c'est risqué de redémarrer de zéro,
- qu'on va repasser par une longue période de débuggage,
- qu'on risque de découvrir un problème qu'on avait pas anticipé,
- etc

Pour moi repartir de zéro, c'est le chemin de l'innovation.


Je pense que le point de vu de M. Spolsky est plus celui d'un employeur :D "ne pas réinventer le fil a couper le beurre car.... ça fait perdre du temps et ça peut coûter plus cher". Bien évidemment, moi même je ne suis pas toujours repartie de zéro lorsque je développais du matériel électronique mais à chaque fois que je l'ai fait j'ai innové et ce n'était pas moins fiable que lorsque je réutilisais.

Citation:

---

Envoyé par Bousk

Tous ses points sont valides, mais il ne faut pas non plus voir le code existant comme le graal et la perfection que l'on ne peut plus atteindre et tout nouveau code comme forcément moins bien.
Je pense qu'un code trop vieux, s'il n'a pas été pensé parfaitement - et plus le code est vieux moins il l'aura été imo -, le faire évoluer devient très difficile voire quasi impossible sans remanier et réarchitecturer un sacré chantier.
De plus ce remaniement aura le même genre d'effets : supprimer du vieux code, réécrire du nouveau, et les problèmes dont il parle peuvent tout autant arriver.
Sans compter qu'un tel chantier sera rarement accepté par les supérieurs, et donc ça finira par du hack ci et là pour corriger le nouveau bug - et quand ils s'accumulent, l'historique des corrections devient de plus en plus un frein à l'évolution..

---

J'ai déjà vu des applications que je qualifie personnellement d'amas de hacks, plein de hacks peuvent donner un soft :ptdr:

Citation:

---

Joel Spolsky, un développeur de logiciels à New York

---

A lire ça on pourrait croire que Joel Spolsky est un développeur lambda, ce qui est loin d'être le cas... Son blog était très suivi à une époque (mais il n'écrit plus beaucoup aujourd'hui), et c'est un des fondateurs de StackOverflow. Il a même son article Wikipedia ;)

Sinon j'aime bien le concept de faire une news à partir d'un article qui date d'il y a 18 ans :P (même si l'article est toujours d'actualité)

Pour revenir au sujet, je suis moins catégorique que Joel Spolsky. Parfois le code existant est une sombre m***e, et on perd moins de temps à repartir de zéro qu'à essayer de régler tous les problèmes du code existant. En d'autres termes, et pour reprendre l'analogie avec l'architecture : si les fondations sont pourries, impossible de construire un immeuble solide dessus. Et si l'immeuble est déjà construit sur des fondations pourries, toucher aux fondations est délicat, voire impossible, sans faire écrouler l'immeuble.

l'histoire de netscape me semble peut viable car entre netscape 4 et 6 la vision n'était plus la même netscape 4 utilisait le système de layer qui fut un mauvais choix et fort possible qu'il fallait soit faire des modification de façon profonde ou repartir de zero de plus il me semble que firefox a été fondé a partir du code de netscape 6.

Je cite un passage important de l'article original :

Citation:

---

As a corollary of this axiom, you can ask almost any programmer today about the code they are working on. “It’s a big hairy mess,” they will tell you. “I’d like nothing better than to throw it out and start over.”

Why is it a mess?

“Well,” they say, “look at this function. It is two pages long! None of this stuff belongs in there! I don’t know what half of these API calls are for.”

[...]

Back to that two page function. Yes, I know, it’s just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I’ll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn’t have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.

Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it’s like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.

When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.

---

À mon avis, le problème de fond de l'exemple ci-dessus, c'est le manque de commentaires dans le code.
Quand les API nous obligent à écrire du code bizarre et contre-intuitif pour que ça marche dans les cas limites, il faut commenter pourquoi on a écrit telle bizarrerie et quel cas particulier cela prend en compte.

De manière générale, chaque fois que l'on écrit un code qui ressemble à du mauvais code, mais qui est justifié si on connaît la raison, alors cette raison doit apparaître dans le code, par exemple sous la forme d'un commentaire. Sinon, le code que l'on écrit est effectivement mauvais et, parmi les développeurs qui reprendront le code et se plaindront de la mauvaise qualité du code, certains auront raison de se plaindre. (D'autres auront tort de se plaindre, car ils feront pareil.)

La problématique avec du code existant c'est qu'au moment de sa création il répondait à un besoin précis.
Puis au fil du temps de la vie du projet , il est surement refactoré plusieurs fois - toujours en urgence, et jamais comme il faudrait - pour finalement au bout de 10 ans ne plus faire du tout ce pour quoi il était prévu à la base (j'exagère à peine). Du coup le code n'est pas forcément mauvais mais la conception initiale n'est plus adapté au nouveau besoin.
C'est dans ces cas là que je juge pertinent de réecrire.

Parfois, c'est l'équipe initiale qui préfère réécrire : évolution du contexte technique (outils) ou recentrage (changement de spécifications larvé : apparaitre à un point B tout en disparaissant du point A, c'est un déplacement).
Il faut des retours utilisateur très précis (qu'est-ce qui est utile, qu'est ce qui sert peu, qu'est-ce qui est gênant/inutile) de sorte à associer une évolution technique à une évolution des spécifications : il faut solidariser la demande, laquelle n'est souvent pas assez forte sur ce genre de projet.
Au niveau maitrise d'ouvrage, une fois n'est pas coutume, il faut des gens compétents sachant demander (et comprendre) des documents de conception justifiant l'effort (à la fois les nouveaux et les anciens ...).
Parfois, un peu de demande de rétro-ingénierie suffit à mettre une nouvelle équipe dans le code d'un ancien projet ...
Je pourrais citer d'autres écueils, mais avec ceux-là, on a déjà 90% des échecs.

J'ai sans doute cité cet article de Joel Spolsky des dizaines de fois en dix ans, et il n'était pas nouveau quand je l'ai personnellement découvert. C'est donc très rigolo de le voir en actualité ce jour.

Ce qu'il dit d'ailleurs, ce n'est pas qu'il ne faut jamais réécrire. C'est qu'il ne faut pas réécrire en oubliant les leçons du passé. J'ai appris à la dure :aie: qu'il avait raison. Une bonne partie des horribles verrues qu'on trouve dans un code ancien sont des réponses à des expériences douloureuses, et qu'il ne faut ps perdre. repartir d'une page blanche en se disant "c'étaient tous des nuls", c'est aller droit dans le mur. Repartir d'une page blanche en se disant "bon, c'est horrible, mais il doit bien avoir une raison pour laquelle ils se sont fait chier à faire ça", par contre, ça marche. Je l'ai fait. Dans la douleur, mais je n'ai perdu aucune des fonctionnalités de ce code de 36 ans d'âge que j'ai entièrement refait depuis zéro.

(Bon, soyons honnête, il y a deux algos, j'ai rien compris, j'ai repris tel quel, et vérifié que le résultat ne changeait jamais, sur une volumétrie de 2 millions de cas de prod, soit un an de traitements. Tout le reste, propre et maintenable. Et le client a mesuré qu'il a économisé plus d'un équivalent temps plein en maintenance, sur les 4 premières années. Pour un projet de 172 jours).

Le problème qui peut se poser aussi c'est qu'un vieux code est écrit avec de vieilles technos et qu'il est dur de recruter de jeunes talents sur des technos obsoletes (on peut les comprendre). Avec un marché de l'emploi des développeurs comme il est aujourd'hui, et les nouveaux langages ou framework qui attirent les jeunes tous les 4 matins, avoir du code "frais" c'est aussi faciliter le recrutement et donc la survie du projet.

Citation:

---

Envoyé par persi

Le problème qui peut se poser aussi c'est qu'un vieux code est écrit avec de vieilles technos et qu'il est dur de recruter de jeunes talents sur des technos obsoletes (on peut les comprendre). Avec un marché de l'emploi des développeurs comme il est aujourd'hui, et les nouveaux langages ou framework qui attirent les jeunes tous les 4 matins, avoir du code "frais" c'est aussi faciliter le recrutement et donc la survie du projet.

---

Certaines applications sur lesquelles je travaille sont encore en Cobol.
Curieusement, je n'ai pas trop de mal à trouver des dev (y compris des jeunes) mais j'ai surtout un gros problème de TJM et de turn over.

Si je prends quelqu'un de déjà formé, le TJM explose et j'ai mon contrôleur de gestion qui bloque.
Et lorsque je prends un jeune que je fais former, j'ai besoin qu'il reste au moins 20 mois sur le poste pour amortir le coût de la formation mais assez souvent, trop souvent, ils partent avant ou en tout cas, beaucoup trop rapidement car une fois formé et avec un peu d'expérience, leur valeur sur le marché grimpe et ils vont au plus offrant.
Je ne peux pas leur en vouloir car j'ai fait de même à mes débuts (après 3 ans dans ma première SSII, je suis parti ailleurs en augmentant mon salaire de 30% d'un coup).

Citation:

---

Envoyé par persi

Le problème qui peut se poser aussi c'est qu'un vieux code est écrit avec de vieilles technos et qu'il est dur de recruter de jeunes talents sur des technos obsoletes (on peut les comprendre).

---

Sachant que l'esprit est modelé par son environnement, cela arrive. Mais il a un instant il c'est plongé dans l'histoire technique, il y a effectivement des chances que les vielles techno aient réussi à séduire comme elles l'ont fait avec les "pionniers". ;)

Citation:

---

Envoyé par persi

Le problème qui peut se poser aussi c'est qu'un vieux code est écrit avec de vieilles technos et qu'il est dur de recruter de jeunes talents sur des technos obsolètes (on peut les comprendre). Avec un marché de l'emploi des développeurs comme il est aujourd'hui, et les nouveaux langages ou framework qui attirent les jeunes tous les 4 matins, avoir du code "frais" c'est aussi faciliter le recrutement et donc la survie du projet.

---

(1) oui, mais si tu fais un code "frais" qui ignore tout l'historique des vieux nanards, tu vas te retaper tooooooous les bugs qui avaient tant fait souffrir tes prédécesseurs. Pas glop. Une refonte de code, ça se fait avec des outillages systématiques de test automatique. C'est ce que dit l'article. C'est ce que j'ai fait.

(2) On peut former des cobolistes, hein. Moi, je n'avais pas d'informatique sur mon CV, on m'a lançé dans le grand bain, et on m'a tutoré. Et j'ai fini par être productif. ce qui nous amène à :

Citation:

---

Envoyé par Saverok

Certaines applications sur lesquelles je travaille sont encore en Cobol.
Curieusement, je n'ai pas trop de mal à trouver des dev (y compris des jeunes) mais j'ai surtout un gros problème de TJM et de turn over.

Si je prends quelqu'un de déjà formé, le TJM explose et j'ai mon contrôleur de gestion qui bloque.
Et lorsque je prends un jeune que je fais former, j'ai besoin qu'il reste au moins 20 mois sur le poste pour amortir le coût de la formation mais assez souvent, trop souvent, ils partent avant ou en tout cas, beaucoup trop rapidement car une fois formé et avec un peu d'expérience, leur valeur sur le marché grimpe et ils vont au plus offrant.
Je ne peux pas leur en vouloir car j'ai fait de même à mes débuts (après 3 ans dans ma première SSII, je suis parti ailleurs en augmentant mon salaire de 30% d'un coup).

---

Pour le turn-over, ben, de toutes façons, il y a le même problème sur les nouvelles technos. On a beaucoup de mal à retenir nos devs, ici. Spécialement les jeunots.

Pour les anciens, c'est le problème des grands comptes, ils sont incapables de s'adapter aux réalités du marché. Ils ont contrôlé les couts pendant 15 ans, et ça leur revient dans la gueule maintenant. si j'étais totalement cynique, je dirais que le marché a attendu que je ne sois plus dans le pool disponible pour exploser niveau tarif(ben oui, je ne tire plus la moyenne vers le bas...). Un vieux qui a vingt ans de bouteille, et qui est capable de corriger un problème avant même que sa hiérarchie ne s'en rende compte, ça a un cout. et il n'y a quasiment plus que ça sur le marché, en effet. J'ai vu entre 2000 et 2014 la qualité moyenne du coboliste moyen croitre radicalement. En 2000, j'étais nul, débutant, et la plupart ne m'arrivaient pas à la cheville. En 2010, j'étais un vétéran efficace, proactif, et apprécié, et il était difficile de trouver moins bon que moi sur le marché.

Fatalement, le TJM augmente, dans ces conditions. Mais tant que l'acheteur moyen ne comprend pas la valeur ajoutée qu'on les cobolistes du jour par rapport à ceux de 2000(une productivité multipliée par 10, au bas mot), ben il ne voit pas pourquoi il devrait ne serait-ce qu'ajuster les tarifs de 2000 par rapport à l'inflation.

Tout ça vient de 3 déformations :

- La croyance dur comme fer dans le "progressisme" : on fait toujours mieux qu'avant, et avant c'était nul. C'est surtout vrai en France depuis la révolution (= on efface tout et on recommence).

- La fausse analogie qu'on établit entre bâtiment et SI. Détruire un vieux bâtiment délabré pour reconstruire est justifié. Mais un SI n'est pas un bâtiment !

- Le sophisme qui consiste à dire: on fait de l'informatique, et l'informatique c'est technique, or la technique évolue très vite, donc il faut que nos SI suivent la technique à la même vitesse. Or on ne fait pas d'informatique, on fait des systèmes d'information.

Citation:

---

Envoyé par rheracles

(.../...)on ne fait pas d'informatique, on fait des systèmes d'information.

---

we have a winner.



Je ne suis pas totalement convaincu par tes deux premiers points, mais celui-là me parait particulièrement pertinent, et balaye tout le reste. enfin, en informatique de gestion, en tous cas. En jeu vidéo, ton raisonnement, il peut poser problème. Mais quand on a la compta d'une banque qui tourne comme du papier à musique depuis 45 ans, quel besoin de se dire "on fout tout à la poubelle pour paraitre moderne" ? Le système d'information est fonctionnel, il répond au besoin. basta.

Citation:

---

Envoyé par Blondelle Mélina

Quand vous jetez l'ancien code et recommencez à zéro, vous jetez toute cette connaissance, toutes ces corrections de bogues, des années de travail de programmation. Vous jetez votre leadership sur le marché. Vous donnez un cadeau de deux ou trois ans à vos concurrents. Vous gaspillez une quantité exorbitante d'argent en écrivant le code qui existe déjà.

---

Vous jetez aussi des verrues écrites par des juniors à qui on a demandé l'impossible alors qu'ils sont pas formés.
Vous jetez des rajouts demandés de type INSERT puis UPDATE UPDATE UPDATE UPDATE UPDATE x 1000
Vous jetez du faux code développé par des charlatans facturés 1000€ la journée qui doivent bien justifier quelque chose.

Il faut faire la part des choses, avec de l'expérience on se rend compte à la première vue qu'une cheville rajoutée est nécessaire (indice, un commentaire du développeur qui dit qu'il a passé 6 semaines à se casser les dents sur une ano pour finalement rajouter cette solution crade, en général j'y touche pas).

En général, quand une société accepte une réécriture complète du code, c'est qu'il est trop tard, et que les solutions qui seront mises pour réindustrialiser seront minimes. Travaillé pour plusieurs éditeurs qui voulaient faire une refonte complète de leur produit. L'ancien code était une plaie. Les leçons ont été prises sur l'architecture et la modélisation. Et pourtant la nouvelle est pire, très souvent pour cause politique (freelances chafouins ayant fleuré le projet chaotique pour facturer comme des malades, embauches de junior à tout va, chefs de projet qui passe plus de temps à faire des réunions que chapeauter leur équipe, bref, vous connaissez tout cela).

Fait rarissimme, je ne suis pas 100% d'accord avec toi.

Citation:

---

Envoyé par Glutinus

Vous jetez aussi des verrues écrites par des juniors à qui on a demandé l'impossible alors qu'ils sont pas formés.
Vous jetez des rajouts demandés de type INSERT puis UPDATE UPDATE UPDATE UPDATE UPDATE x 1000
Vous jetez du faux code développé par des charlatans facturés 1000€ la journée qui doivent bien justifier quelque chose.

---

Je vais essayer de te faire prendre un autre point de vue : ce n'est pas parce que c'est techniquement atroce que c'est fonctionellement inutile. Exemple vécu de boucle avant et après refactorisation :

Code:

---

1 2 3 4 5 6 7 8 9 10

A121. MOVE 1 TO II. MOVE 0 TO YY. A120. ADD ZZ(II) TO YY. ADD 1 TO II IF II > TT GO TO A139. GO TO A 121. A139. EXIT.

---

refait correctement(bon, j'ai été bourrin en donnant un no signifiant à l'index, suivant les sites, ça sera encouragé ou découragé)(a noter aussi qu'il n'y a pas de passage de paramètres en cobol, donc la portée des données est niveau programme, pas niveau procédure - donc les variables que j'utilise ont été définies ailleures et passent par globalité - un de mes rares reproches au COBOL, mais un costaud) :

Code:

---

1 2 3 4 5 6

CALCUL-TAXE-ASSURANCE. MOVE ZERO TO TOTAL-TAXE PERFORM VARYING POSITION-ELEMENT FROM 1 BY 1 UNTIL POSITION-ELEMENT > TOTAL-ELEMENTS-TAXE ADD ELEMENT-TAXE (POSITION-ELEMENT) TO TOTAL-TAXE END-PERFORM .

---

Le code initial ne respecte rien, pas même la logique élémentaire dans le nommage des labels de destination des GO TO. Pourtant, il fait une tâche essentielle, à savoir cumuler les différents éléments comptables qui composent la taxe d'assurance(le vrai algo était bien plus relou, mais j'ai simplifié pour l'exemple. De toutes façons, j'ai oublié les détails).

Le code final respecte à peu près tout les éléments qui faisaient un code COBOL propre il y a 10 ans(il y a peut-être eu des progrès depuis, et certains détails varient d'une boite à l'autre, comme le nommage des index ou la présence-absence d'un label de fin de paragraphe.). Il n'invente strictement rien au niveau fonctionnel, il se contente d'amener visuellement au mainteneur tout ce dont il a besoin pour comprendre rapidement ce qui se passe sur ce bout de code.

les update horribles de tes escrocs sont peut-être des crimes contre l'humanité, mais ils ont été faits dans un but précis. Tout refaire autrement, soit, mais être bien sur de ne rien oublier.

Citation:

---

Envoyé par Glutinus

Il faut faire la part des choses, avec de l'expérience on se rend compte à la première vue qu'une cheville rajoutée est nécessaire (indice, un commentaire du développeur qui dit qu'il a passé 6 semaines à se casser les dents sur une ano pour finalement rajouter cette solution crade, en général j'y touche pas).

---

Mais les sagouins qui ont fait sans talent du cobol à la façon assembleur sale en 1972 n'avaient laissé aucun indice de ce genre. Pourtant, leur horreur tournait, et donnait des résultats fonctionellement justes. Il me fallait reprendre leur savoir fonctionnel, à la virgule près, tout en me débarrassant de leurs obsolescences vomitoires techniques. Le test a évidemment été essentiel. Il fallait comparer les résultats(je ne me suis pas fait chier, je passais un mois complet de production, avec 300,000 avis générés, ça permet de couvrir à peu près tous les cas).

Citation:

---

Envoyé par Glutinus

En général, quand une société accepte une réécriture complète du code, c'est qu'il est trop tard, et que les solutions qui seront mises pour réindustrialiser seront minimes. Travaillé pour plusieurs éditeurs qui voulaient faire une refonte complète de leur produit. L'ancien code était une plaie. Les leçons ont été prises sur l'architecture et la modélisation. Et pourtant la nouvelle est pire, très souvent pour cause politique (freelances chafouins ayant fleuré le projet chaotique pour facturer comme des malades, embauches de junior à tout va, chefs de projet qui passe plus de temps à faire des réunions que chapeauter leur équipe, bref, vous connaissez tout cela).

---

Mais ça, ce n'est pas lié à la discipline de la refonte. C'est lié au fait qu'on manque de gens talentueux à tous les niveaux(je ne m'appesantirais pas sur les causes, je n'ai pas la vérité absolue à ce sujet). Moi, j'ai mené plusieurs refontes complètes dans ma carrière, même si je cite toujours la même (la plus violente et la plus spectaculaire). Avec succès. Seul, ou en équipe. Avec l'aide du management, ou contre lui. Des gens de qualité en projet "feuille blanche" auront le même palmarès que moi, et des gnous auront le même taux de succès que ceux que tu as subi sur les refontes.

Ce putain de code avait 36 ans. Ca faisait plus de 10 ans que les internes faisaient des pieds et des mains pour avoir le budget de la refonte, et que la direction les envoyait chier. Ils l'ont fait passer au prétexte d'un changement de format de sortie(au lieu de faire les impressions en mode texte, on envoyait désormais les données fonctionnelles à des moulinettes pour présentation moderne), et dit "ce n'est pas possible sans une refonte complète" (ils avaient raison, mais ils ne le savaient pas, ils ont juste sauté sur l'occasion avant même de faire l'analyse). Une fois le budget débloqué, aucun d'entre eux n'a voulu prendre le bébé, et j'ai débarqué avec un collègue. On a fait le boulot. On s'est cassés(et la chef a récolté tous les lauriers). Ils ont estimé, au bout de 4 ans, le gain en termes de maintenances à 1,2 équivalent temps plein.

Donc ça peut marcher. Mais il faut trouver les bonnes personnes sur le marché. Et pour ça, il faut qu'elles y soient. Je n'y suis plus, et mon collègue non plus, ça fait déjà deux de moins. On peut avoir de la chance avec les petits jeunes, mais c'est toujours un risque. :aie:

Citation:

---

Envoyé par el_slapper

a noter aussi qu'il n'y a pas de passage de paramètres en cobol, donc la portée des données est niveau programme, pas niveau procédure - donc les variables que j'utilise ont été définies ailleures et passent par globalité - un de mes rares reproches au COBOL, mais un costaud

---

Je n'y connais rien en COBOL, mais j'ai lu sur Wikipédia que, depuis COBOL 2002, on a les fonctions définies par l'utilisateur et on peut même faire de la programmation orientée objet. Si c'est vrai, alors cela devrait permettre d'améliorer significativement l'architecture du nouveau code.

L'orienté objet, comme d'autres paradigmes de haut niveau, permet de faire de l'inversion de dépendance, ce qui permet de découper davantage le code en briques réutilisables. Par exemple, l'inversion de dépendance permet de mettre en place des mocks qui facilitent les tests unitaires.

Citation:

---

Envoyé par Pyramidev

Je n'y connais rien en COBOL, mais j'ai lu sur Wikipédia que, depuis COBOL 2002, on a les fonctions définies par l'utilisateur et on peut même faire de la programmation orientée objet. Si c'est vrai, alors cela devrait permettre d'améliorer significativement l'architecture du nouveau code.

---

C'est vrai, mais c'est méga lourdingue, et ça ne vaut le coup que pour de très gros trucs. Faire 20 lignes de plomberie pour une fonction de 3 lignes, buerk. On est pas en LISP. Je préfèrais encore faire des modules séparés pour des gros codes répétables, comme ça on pouvait les réutiliser le cas échéant. Pour les petits trucs, une bête procédure avec juste un label(appelé proprement et pas par GO TO, évidemment) et des données malheureusement pas encapsulées, ça reste le meilleur compromis, et de loin. Évidemment, dans d'autres langages, il faut faire de manière plus traditionnelle(i.e. ne pas hésiter à faire des routines locales paramétrisées très courtes en grand nombre).

Citation:

---

Envoyé par Pyramidev

L'orienté objet, comme d'autres paradigmes de haut niveau, permet de faire de l'inversion de dépendance, ce qui permet de découper davantage le code en briques réutilisables. Par exemple, l'inversion de dépendance permet de mettre en place des mocks qui facilitent les tests unitaires.

---

La programmation orientée objet en COBOL, c'est encore pire. Je n'ai jamais réussi à en compiler. Et de toutes façons, les exemples que j'ai lu, c'est dans les 50 lignes de plomberie juste pour faire une classe avec une propriété.....

Le truc aussi, c'est que la plupart des cobolistes ne sont pas de vrais informaticiens. J'ai bouffé beaucoup de théorie en ces lieux, mais la plupart des autres cobolistes non. Avec les années, il y a eu un écrémage terrible, et ne restent souvent que les meilleurs. Mais les meilleur avec la boite à outil de COBOL 77, pas 2002. Qui font des trucs hyper propres, avec les moyens de l'époque. "l'inversion de dépendance permet de mettre en place les mock", c'est typiquement le genre de phrase qui te met tous les cobolistes à dos. Je ne dis pas que tu as tort, je dis que dans ce monde-là, cette manière de penser ne passe pas. Et ça ne fait pas de mes ex-collègues des mauvais, loin s'en faut. Simplement, ils utilisent des outils plus anciens, qui ont fait leurs preuves, et vont éviter des surcouches de complexité.

La vraie raison d'être de la surcouche objet en COBOL, c'est de pouvoir être appellé plus facilement par du JAVA, dans des architectures ou le JAVA fait toute l'interface(et, de plus en plus souvent, les couches intermédiaires), mais ou le COBOL reste maitre sur les couches basses d'accès aux données. Dans ce cas, on fait juste un objet chapeau, le reste ont le fait à l'ancienne. Parcequ'au vu des qualités, et aussi des défauts du COBOL(et aussi vu la sociologie des gens qui en font), multiplier les classes, c'est du suicide.

Je viens de coder un petit truc dans mon boulot actuel dans un langage objet(un truc maison, je passe les détails). Une injection de fichier. J'ai fait 8 classes. En COBOL, c'eut été aberrant. J'aurais fait un programme principal, avec quelques sous-modules, et surtout pas de classes. Les manières de penser qui conviennent bien sur des langages type JAVA(et notre langage maison ressemble beaucoup) ne conviennent pas du tout au COBOL, et vice versa. C'est aussi pour ça que les reconversions des cobolistes se passent généralement très mal. Les formateurs connaissent parfaitement JAVA, et n'ont que mépris pour "ce langage de merde" (sans lequel ils ne seraient pas payés, ni personne d'autre), et inondent de grands professionnels, des gens qui ont fait leurs preuves dans des conditions difficilles, de théories qui ne leurs parlent pas.

Si tu donnes à ces gens-là la définition classique de la classe "En programmation orientée objet, la déclaration d'une classe regroupe des membres, méthodes et propriétés (attributs) communs à un ensemble d'objets. La classe déclare, d'une part, des attributs représentant l'état des objets et, d'autre part, des méthodes représentant leur comportement. Une classe représente donc une catégorie d'objets. Elle apparaît aussi comme un moule ou une usine à partir de laquelle il est possible de créer des objets ; c'est en quelque sorte une « boîte à outils » qui permet de fabriquer un objet. On parle alors d'un objet en tant qu'instance d'une classe (création d'un objet ayant les propriétés de la classe)." , tu les a perdus irrémédiablement.

Si tu leur parle leur langage, à savoir, "une classe, c'est une COPY de données, et les propriétés qui vont sur les données, des niveaux 88 sous stéroïdes, programmables", là, tu vas pouvoir les convaincre. Mais personne ne fait ça. Tu n'as pas fait ça. Moi, je suis entre deux, donc je vois parfaitement ou tu veux en venir. Mais par pitié, ne leur parle jamais comme ça.

En entreprise, on passe son temps a refaire du code développé en externe ou par des stagiaires ou pire encore, du code que l'on a écrit il y a deux ans en entrant dans la boite.

Refactoriser des blocks entiers de l'application pour éliminer les redondances, améliorer les performances, virer des dépendances vers des librairies fumeuses, faire de la place pour introduire de nouvelles fonctionnalités, est le quotidien des développeurs en entreprise. Refactoriser coûte à peine la fraction du coût de développement d'un soft complet.

On ne devrait probablement jamais réécrire une application à partir de 0 sauf si
1/ le coût est négligeable
2/ la technologie est obsolète ou a atteint ses limites (exemple Twitter réécrivant son backend de ruby ou python en Java ou Scala mais en tout cas passant sur la JVM)
3/ personne n'est capable de maintenir l'application sans sa forme actuelle, que cela soit à cause des limites du langage ou de la mauvaise architecture du système (cas le plus rare)

Evidemment ce paradigme peut ne pas plaire aux SSII qui besoin de vendre de la presta par container entier, et qui donc vont tout faire pour envoyer un consultant faire son audit et annoncer que le code existant est trop vieux pour être maintenu.
Pensez donc, il n'est pas écrit dans le langage hype du jour (qui sera obsolète dans 2 ans), et n'utilise pas le dernier design pattern machin (que le client final ne voit jamais). Heureusement la SSII en question a justement une armée de jeunes développeurs (pas chers) formés (la veille) sur cette technologie et expert (car jeunes).

Ou alors ce sera le nouvel architecte/urbaniste/CEO qui veut tout casser pour faire une grosse refonte de tout l'existant. Forcément meilleure puisque c'est la sienne et que toute façon il est plus commode d'imaginer ce que sera l'avenir que de comprendre ce qu'est l'existant.

Or sachant que 75% des projets informatiques échouent et continue d'échouer, la refactorisation apparait donc comme un choix beaucoup plus sur.

D'ailleurs au final, quand je compare Netscape 4 avec ses successeurs, il n'y a pas photo : il était infiniment supérieur.

Cela se passe dans l'entreprise que vous voulez. Une équipe nouvellement recrutée reprend un projet :

"On a du tout refaire de zéro parce que le code était affreusement mal écrit."

Quelques années plus tard, une autre nouvelle équipe reprend le projet à son tour :

"On a du tout refaire de zéro parce que le code était affreusement mal écrit."

L'employeur :

"Putain mais virez-moi tous ces nuls !"

Citation:

---

Envoyé par ddoumeche

On ne devrait probablement jamais réécrire une application à partir de 0 sauf si
1/ le coût est négligeable
2/ la technologie est obsolète ou a atteint ses limites (exemple Twitter réécrivant son backend de ruby ou python en Java ou Scala mais en tout cas passant sur la JVM)
3/ personne n'est capable de maintenir l'application sans sa forme actuelle, que cela soit à cause des limites du langage ou de la mauvaise architecture du système (cas le plus rare)

---

Je ne sais pas si c'est si rare que ça. Des architectures monolithiques, qui ont grossi, grossi au fil des ans sans fil directeur, sans normes de développement, sans relecture de code, pas ou très peu de tests unitaires, pas ou très peu de documentation, des centaines de milliers de lignes de procédures stockées en PL/SQL que, parfois, personne ne comprends réellement, la connaissance métier qui s'évanouit avec le départ du presta. Tout ça, c'est un peu notre quotidien à tous, non ?

Alors le besoin de repartir sur des bases propres, sur une architecture saine, maintenable, scalable, se conçoit.

Le problème c'est qu'en pratique... combien de projets de refonte globale reproduisent les erreurs de l'existant, tout en ajoutant leurs propres erreurs de conception ? :aie:

Citation:

---

Envoyé par Grogro

Je ne sais pas si c'est si rare que ça. Des architectures monolithiques, qui ont grossi, grossi au fil des ans sans fil directeur, sans normes de développement, sans relecture de code, pas ou très peu de tests unitaires, pas ou très peu de documentation, des centaines de milliers de lignes de procédures stockées en PL/SQL que, parfois, personne ne comprends réellement, la connaissance métier qui s'évanouit avec le départ du presta. Tout ça, c'est un peu notre quotidien à tous, non ?

---

Non... car on ne fait pas beaucoup appel aux prestas :aie:

Enfin nuançons, je n'ai pas la (mal)chance de faire du PL/SQL, même si SQL Server étant + ou - isofonctionnel, on peut aussi faire beaucoup de merde avec. Et j'en vois donc passer souvent, ce qui est inévitable avec un langage de script, donc sans versioning, compilation, typage "dynamique", tests unitaires et j'en passe.
Pour d'autres projets, on fait au contraire le maximum de traitement coté business, quitte à ce que cela soit légèrement plus lent : rajouter des serveurs d'application n'est ni compliqué ni cher, alors la base de donnée n'est pas aussi scalable. Par contre, elle est versionnée.

C'est pour cela que l'urbanisation est un challenge, et qu'on doit former des architectes, des dba, enseigner Merise.
Et non pas faire de l'Agile sans plan d'architecture ou spécifications techniques voir fonctionnelles.

D'ailleurs, la relecture de code est le boulot du chef d'équipe et de l'architecte, et si le code n'est pas documenté le presta n'est pas payé. On utilise souvent javadoc + un bête wiki pour la documentation, avant d'exporter cela dans un beau document tout propre grâce à un script fait par le devops :)

Citation:

---

Envoyé par Grogro

Alors le besoin de repartir sur des bases propres, sur une architecture saine, maintenable, scalable, se conçoit.

---

Oui, c'est le cas n°2 & 3 : technologie vieillissante (oracle) et difficile à maintenir, mauvaise réalisation. Est-ce une mauvaise architecture pour autant ?

Mais on est pas obligé de refaire tout d'un coup, un système qui a pris 10 ans développement peux être refait par blocs, ou par district, ou par périmètre. Par exemple, juste l'IHM voir des bouts de l'IHM vu que tout est accessible par URL de nos jours. Ou juste des parties précises du backend. On a ainsi des projets sortant des livrables régulièrement et pouvant donc mieux survivre au départ d'un responsable.

Quand Haussman refait Paris, il ne rase pas la ville, il procède par arrondissements même si cela prend 30 ans.

Et puis on peut imaginer des passerelles : Par exemple, là lancer un crash program pour faire tourner du code Javascript dans nos serveurs Java via le runtime V8 de google. Cela marche plutôt bien, et résout les problèmes de Node.js à savoir le monoThreading, le rechargement des classes, la sécurité (nodejs donne accès à tout le filesystem), bref presque tout.

En plus de donner accès (en théorie) à une grosse partie de notre API java aux développeurs Javascript, donc pas besoin de réécrire de SQL, HSQL ou PL/SQL.

On pourra même déboguer expérimentalement le code javascript coté serveur dans Chrome .. ou dans Eclipse. Et à mon avis, c'est adaptable dans d'autres type de solution ou de projets.

Bref, je suis sur que chacun d'entre nous face à son vieux SI est capable d'amélioration continue. Et donc de tirer les enseignements des erreurs du passé.

Citation:

---

Envoyé par Grogro

Le problème c'est qu'en pratique... combien de projets de refonte globale reproduisent les erreurs de l'existant, tout en ajoutant leurs propres erreurs de conception ? :aie:

---

Un projet sans bug, c'est un projet inutilisé.

Citation:

---

Envoyé par el_slapper

... Exemple vécu de boucle avant et après refactorisation :

Code:

---

1 2 3 4 5 6 7 8 9 10

A121. MOVE 1 TO II. MOVE 0 TO YY. A120. ADD ZZ(II) TO YY. ADD 1 TO II IF II > TT GO TO A139. GO TO A 121. A139. EXIT.

---

---

... ce bout de code COBOL est non seulement " vieillot " mais en plus j'ai l'impression qu'il est faux ... ne serait ce pas plutôt ?

Code:

---

1 2 3 4 5 6 7 8 9 10

A121. MOVE 1 TO II. MOVE 0 TO YY. A120. ADD ZZ(II) TO YY. ADD 1 TO II IF II > TT GO TO A139. GO TO A120. A139. EXIT.

---

Déjà on ne touche pas quelque chose qui fonctionne et donne satisfaction sans bonne raison. Par exemple j’ai écrit des programmes de facturation sur AS400 dans les années 90 et qui sont encore utilisés en 2018 bien que j’aie quitté la boîte il y a 15 ans et qu’il n’y ait plus de maintenance depuis des années.


Dans ma carrière il m’est arrivé de devoir reprendre des développements faits par d’autres et pleins de bogues.
Dans les cas où je ne connaissais pas spécialement le domaine fonctionnel je reprenais le code et essayais de le corriger et le plus marrant c’est que souvent la correction d’un bogue en débloquait d’autres qui n’étaient jamais apparus puisque masqués par le bogue inital !
Par contre dans les cas où je connaissais le fonctionnel il m’est arrivé plus d’une fois de tout réécrire du moment que même le cas de test le plus simple ne fonctionnait pas ou bien parce que c’était tout bonnement très mal écrit et inmaintenable. Tant qu’à être responsable au final autant que ce soit avec son propre code ! Parce qu’il ne faut pas se leurrer du moment qu’on a mis un ongle dedans on devient le responsable surtout si c’est une partie critique.


Comment vois-je que le code est mal écrit ? Tout simplement parce que le code n’est pas beau ! La beauté est subjective me direz-vous. Mais tout au long de ces années j’ai remarqué que le code qui est bien proportionné doté d’une certaine symétrie est moins sujet aux bogues et est plus facilement maintenable et évolutif qu’un code asymétrique qui part dans tous les sens. Car s’il est asymétrique c’est qu’il y a sûrement un cas fonctionnel qui n’a pas été traité.

Citation:

---

Envoyé par wolinn

En principe, dans une entreprise qui fonctionne normalement, ce ne sont pas les développeurs lambda qui devraient prendre la décision de réécrire un projet.

---

ce n'est pas qu'un problème décisionnel c'est surtout un problème de financement oui !
Ré-écrire un projet c'est tout un budget tout un investissement bien souvent il faut réecrire la doc technique et fonctionnelle.
En plus c'est mettre des développeurs et architectes,analystes sur un projet x heures par jour donc tout cela coûte de l'argent

Citation:

---

Envoyé par badaze

Déjà on ne touche pas quelque chose qui fonctionne et donne satisfaction sans bonne raison.

---

c'est exact c'une des règles numéro un dans l'économie,la production et l'industrie.
Cependant avec les évolutions de la technologie, les éditeurs de solutions poussent les utilisateurs de systèmes informatiques ( bref les entreprises ) à refaire les projets informatiques.
Ce qui coûte de l'argent encore une fois

Citation:

---

Envoyé par badaze

Comment vois-je que le code est mal écrit ? Tout simplement parce que le code n’est pas beau ! La beauté est subjective me direz-vous.

---

ok mais du code informatique n'a tout de même pas vocation à ressembler à la Venus de Botticelli tout de même :mrgreen:

Citation:

---

Envoyé par Mat.M

ok mais du code informatique n'a tout de même pas vocation à ressembler à la Venus de Botticelli tout de même :mrgreen:

---

Quel manque de sens artistique.

Pour le moment pas eu besoin de réécrire tout de zéro, on réutilise, on modifie l'existant et on prévoit de migrer une partie du soft l'an prochain car le matériel qui devient obsolète.
Et ça ne sera pas du luxe car je trouve qu'on s'approche un peu trop des limites du hardware.

Citation:

---

Envoyé par badaze

Comment vois-je que le code est mal écrit ? Tout simplement parce que le code n’est pas beau ! La beauté est subjective me direz-vous. Mais tout au long de ces années j’ai remarqué que le code qui est bien proportionné doté d’une certaine symétrie est moins sujet aux bogues et est plus facilement maintenable et évolutif qu’un code asymétrique qui part dans tous les sens. Car s’il est asymétrique c’est qu’il y a sûrement un cas fonctionnel qui n’a pas été traité.

---

Qu'est-ce qu'un code "symétrique et bien proportionné" ?

@Grogro

J'ai énormément de mal à formaliser cette notion. C'est plus une impression comme quand on regarde une peinture dans sa globalité sans se focaliser sur les détails. Il y a une harmonie dans la structure comme une sinusoïdale, c'est apaisant. A contrario un source mal écrit part dans tous les sens.

Ca m'est arrivé de reprendre un algorithme que j'étais en train d'écrire et qui (j'en suis sûr) aurait fonctionné seulement parce qu'il ne répondait pas à ce canon de beauté.

Je tombe par hasard sur cet article en cherchant totalement autre chose.

L'argument pour dire de ne pas reprendre à zéro serait donc, que l'accumulation de code est également une accumulation d'expérience sur le code… ?
Sauf que « l'expérience » impliquerait que le code ait été proprement fait (sans jamais aucune précipitation héhé), correctement commenté pour expliquer pourquoi telle ou telle chose a été faite (notamment sur les points qu'un développeur passant par là pourrait juger aberrant sans savoir), que la documentation (à laquelle beaucoup de développeur sont allergiques et cherchent souvent des excuses pour ne pas s'en occuper *triste*) est tenue à jour et qu'on peut s'y fier, etc…

La réalité est qu'un projet qui n'a subit AUCUNE maintenance depuis un certains temps et qui n'a plus aucun collaborateur historique pour passer le savoir devient une couche sédimentaire qu'on ne peut plus faire évoluer et qui devient potentiellement une faille de sécurité monstrueuse. Le principe de l'amélioration continue d'un programme ne peut s'appliquer que si le projet n'a pas connu d'interruption sévère. Dès lors malheureusement, quand un product owner a perdu la maîtrise de son code, et qu'il souhaite évoluer, il n'y a souvent pas d'autre choix que de repartir de zéro…

Non pas que ça soit nécessairement un plaisir pour le développeur qui s'y atèle.

My two cents…

Pour répondre à el_slapper sur sa réponse vieille de deux ans, mais dont je me souviens un peu, la lecture fait partie de la maintenabilité du code, évidemment. Je n'ai rien contre un code un peu pourrave, pour peu qu'il est lisible et propre un minima. Mon credo serait un peu "First, make it work ; then, make it readable ; finally, make it quick". Parce que malgré toutes les pierres qu'on pourrait jeter aux gens, le but c'est quand même d'avoir des prémices de résultat...
Après c'est tout un jugement de penser : ce que je fais est-il maintenable ?

Evidemment que ton premier code est plus lisible, maintenant si le second faisait l'affaire il avait raison de rester là... sauf si bien sûr de nouvelles priorités apparaissent (comme par exemple un temps de traitement) prenait les devants.

Pour répondre à la question de l'INSERT + UPDATE + UPDATE + UPDATE, qui est ce que j'ai subi chez un client, cela répondait à moitié à une demande utilisateur. Il y avait un "pas de commit", c'est à dire un commit tous les 10.000 insertions (donc du PL/SQL) pour que le client ait quand même une partie des données même si ça plantait. Quand j'ai vu ça, première question à la chef de projet : est-ce le besoin ? Sa réponse : Oui. Donc je n'ai pas touché à ce concept.
Le problème est que toute évolution sous forme de nouvelle colonne, si j'en crois les cartouches de commentaires (le seul truc qui était vraiment bien fait chez ce client), a été faite par le même développeur qui a fait l'évolution en système source, avec comme consigne, quick and dirty. Il a donc copié-collé le code, transformé l'insert en update.
Problème 1 : il y a donc un million instructions UPDATE, autant que de clés, multiplié par le nombre de colonnes rajoutées.
Problème 2 : le temps de traitement de l'ensemble de l'Infocentre dépassa allègrement les 24h, provoquant le courroux des clients qui, pour une raison obscure, trouvent que le reporting est désormais inutilisable.

Cela demanda évidemment un nouvel entretien client, du haut des mes un an d'expérience et de mon menton imberbe (< métaphore du jeune développeur) :
Est-ce que le passage en moins de 24h est critique : réponse oui.
Voulez-vous garder ce système de "si ça plante, je veux quand même les données jusque là". Réponse : oui.
Voulez-vous que je réécrive le code avec un seul INSERT en jointure, avec recette en TNR et temps de traitement réduit : m'en fiche, c'est vous l'expert.

(A noter que mon client pour qui j'étais presta, éditeur, est étonnamment contre toute forme de travail non facturée au client, donc le plus gros de mon travail est de négocier ce temps de correction que j'imputais évidemment sur de l'anomalie bloquante, puisque c'est moins fatigant pour lui que de négocier avec ses propres clients).

Résultat : beaucoup moins de temps de traitement, avec une fragilité robustesse identique au différent (taux d'échec de chargement, dû généralement à l'ETL merdique qui nous donnait aucune log du plantage).

Bon derrière tout ce charabia technique qui ne passionne que qui voudra (et étant donné que ça a plus de dix ans et que j'étais jeune, est tout à fait critiquable et débattable, et ce même entre mon moi 2020 et mon moi 2006), la performance a été corrigée, les résultats sont les mêmes, la robustesse identique, et AMHA était un peu plus lisible.

Dans un monde idéal évidemment, on travaille sous forme d'audit pour identifier les pieds d'argile du code et prioriser les besoins clients, ce qui est selon moi de plus en plus difficile aujourd'hui car on ne les accompagne plus du tout dans ce genre de travail (ie on supprime beaucoup de poste de ces parasites de Business Analyst, malheureusement les bons qui savent travailler et qui font parfaitement l'interface-tampon entre technique et utilisateurs en pâtissent grave).

Citation:

---

Envoyé par badaze

C'est plus une impression comme quand on regarde une peinture dans sa globalité sans se focaliser sur les détails. Il y a une harmonie dans la structure comme une sinusoïdale, c'est apaisant. A contrario un source mal écrit part dans tous les sens.

---

+1 bien vu.
C'est à quoi sert la compression jpeg puisque le principe c'est la transformée en cosinus discret.

Maintenant que la vérité du monde réside dans les décimales de Pi 3.14 comme le suggèrait Pythagore je vous laisse débattre dessus :D

Cela me rassure de lire que personne n'a choisi l'option "Je refuse de travailler sur un autre code que ceux que j'ai créés de A à Z". :mouarf: