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 !

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

Le , par Blondelle Mélina

104PARTAGES

17  0 
Que faites-vous le plus souvent ?
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.


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 ?

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

Voir aussi :

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

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

Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 01/05/2018 à 18:55
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 (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.
9  0 
Avatar de Vincent PETIT
Modérateur https://www.developpez.com
Le 01/05/2018 à 11:47
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 "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.
9  1 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 02/05/2018 à 12:23
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 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).
8  0 
Avatar de Bousk
Rédacteur/Modérateur https://www.developpez.com
Le 01/05/2018 à 9:12
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..
7  0 
Avatar de onilink_
Membre expérimenté https://www.developpez.com
Le 01/05/2018 à 9:51
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.
6  0 
Avatar de Pyramidev
Expert confirmé https://www.developpez.com
Le 01/05/2018 à 23:12
Je cite un passage important de l'article original :
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.)
6  0 
Avatar de ddoumeche
Membre extrêmement actif https://www.developpez.com
Le 08/07/2018 à 0:20
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.
6  0 
Avatar de grunk
Modérateur https://www.developpez.com
Le 02/05/2018 à 8:24
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.
5  0 
Avatar de wolinn
Membre éprouvé https://www.developpez.com
Le 01/05/2018 à 7:43
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é.
4  0 
Avatar de tpericard
Membre averti https://www.developpez.com
Le 01/05/2018 à 10:47
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
4  0