Dilemme de la reprise de projet : tout détruire ou pas ?

Durant ma carrière, j'ai souvent été confronté à la même question. En face d'un projet biscornu, quel était la meilleure solution ?

Le dilemme de la reprise de projet sur CommitStrip

Soit on appelle la boule de démolition, soit on rénove. Qu'est ce que prendra moins de temps ? Qu'est ce qui est le mieux ?

Le jeune stagiaire plein de bonne volonté n'a pas très envie de reprendre du code existant. Il est toujours plus agréable de repartir de zéro, de tout reconstruire. Au moins, ce sera notre logiciel, pas celui d'un autre.

Mais attention, la plupart du temps, repartir de zéro est une très mauvaise idée. C'est très séduisant, les développeurs vous vanteront les défauts du code existant, les mérites des nouvelles technologies, et puis que les vieux n'y comprennent rien, ou que le stagiaire a fait n'importe quoi.

Dans l'article Les choses que vous ne devez jamais faire, l'auteur Joel Spolsky préconise de ne jamais repartir de zéro. Repartir de zéro implique de ne plus avoir un produit livrable. Et perdre le potentiel d'avoir un produit livrable, c'est perdre un marché. On perd aussi des informations précieuses que les anciens développeurs ont déjà découverts : bugs de compatibilité, règles fonctionnelles biscornues... Il faut tout reprendre, tout revoir, êtes vous sûr que cela ne vas pas prendre plus de temps ?

Dans mon projet actuel, on est parti de très loin. Le logiciel était en ruine, programmé de la pire des manières : variables globales, aucune instance d'objet, code non optimisé (pour les connaisseurs, le tri à bulle était utilisé de partout), non hiérarchisé, environ 100.000 lignes de code répartit dans une vingtaine de fichiers, sans aucun dossier. On m'a embauché pour remettre de l'ordre, allais-je repartir de zéro ?

Le logiciel était utilisé par trois personnes de manière intensive. Ils avaient besoin de correction, maintenant, pas dans un an. Réécrire de zéro m'aurait pris au moins une année pleine, et encore, c'est optimiste. Les utilisateurs ne pouvaient pas rester avec un logiciel inefficace pendant toute une année, car cela allait impacter directement sur la production de l'entreprise.

J'ai choisi de faire une rénovation complète du logiciel, en conservant constamment une version livrable et fonctionnelle, moins pire que la précédente. Cela a été difficile et compliqué. Il a fallut se battre contre la médiocrité, corriger les aberrations, être confronté au jour le jour à des absurdités. Il est plus difficile de lire du code que de l'écrire. C'est éprouvant émotionnellement de reprendre le code d'autrui, d'autant plus quand il est mauvais. Imaginez-vous lire `Les misérables` en langage sms.

Cependant, les bénéfices ont été innombrables. Les utilisateurs ont pu voir au cours de l'année des améliorations visibles et décisives. Les temps de calculs fondaient à vue d’œil, les bugs devenaient de plus en plus rares, le logiciel devenait fiable, robuste et performant. Et le plus important, les utilisateurs reprenaient confiance dans le logiciel. Ils n'en avaient plus peur, ils avaient envie de l'utiliser, la productivité devenait meilleure.

Bien sur, la taille du projet rentre en compte. Si vous avez quelques centaines de lignes de code, il vaut peut être mieux tout reprendre de zéro. Mais rapidement, si vous commencer à dépasser quelques milliers de lignes, réfléchissez bien à l'impact de repartir de zéro.