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, Expert confirmé
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


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


 Poster une réponse Signaler un problème

Avatar de wolinn wolinn - Membre éclairé 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é.
Avatar de Bousk 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..
Avatar de - https://www.developpez.com
le 01/05/2018 à 9:32
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...
Avatar de onilink_ onilink_ - Membre éclairé 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.
Avatar de cirle78 cirle78 - Membre régulier https://www.developpez.com
le 01/05/2018 à 10:40
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...
Avatar de tpericard tpericard - Membre actif 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
Avatar de clorr clorr - Membre du Club https://www.developpez.com
le 01/05/2018 à 11:12
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.
Avatar de Vincent PETIT 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.
Avatar de redcurve redcurve - Membre averti https://www.developpez.com
le 01/05/2018 à 12:15
Citation Envoyé par Bousk Voir le message
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
Avatar de tomlev 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.
Contacter le responsable de la rubrique Accueil