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 
(même si l'article est toujours d'actualité)
Envoyé par Joel Spolsky
"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.
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.