Réécrire ou réparer ?

Question

Je suis sûr que vous êtes tous passés par là, vous entreprenez un projet dans lequel il existe une vieille base de code grinçante qui est à peine adaptée à son objectif et vous devez prendre la décision de la réécrire à partir de zéro ou de réparer ce qui existe déjà.

La sagesse conventionnelle tend à suggérer que vous ne devriez jamais tenter de réécrire à partir de zéro, car le risque d’échec est très élevé.Alors, qu’avez-vous fait face à ce problème, comment avez-vous pris la décision et comment cela s’est-il passé ?

Answer 1

Cela dépend vraiment de la gravité de la situation.

S'il s'agit d'un petit système et que vous le comprenez parfaitement, alors une réécriture n'est pas folle.

D'un autre côté, s'il s'agit d'un monstre géant hérité avec dix millions de lignes de code mystérieux non documenté, alors vous allez vraiment avoir du mal avec une réécriture complète.

Points à considérer:

• Si cela a l'air bien pour l'utilisateur, il ne se soucie pas du type de gâchis spaghetti que c'est pour vous.D'un autre côté, si c'est mauvais pour eux aussi, il est plus facile d'obtenir un accord (et une patience).
• Si vous réécrivez, essayez de le faire une partie à la fois.Une base de code désorganisée et désorganisée peut rendre cela difficile (c'est-à-dire que le remplacement d'une seule partie nécessite une réécriture de grands icebergs de code de dépendance), mais si possible, cela facilite la réécriture progressivement et l'obtention des commentaires des utilisateurs en cours de route en cours de route .

J'hésiterais vraiment à me lancer dans un projet de réécriture géant pour un grand système sans pouvoir publier la nouvelle édition une partie à la fois.

Answer 2

Nettoyez simplement un peu le code à chaque fois que vous travaillez avec.S'il n'y en a pas déjà un, configurez un cadre de tests unitaires.Tout nouveau code doit faire l’objet de tests écrits.Tout ancien code que vous corrigez à la suite de bugs, essayez également d'y glisser des tests.

Au fur et à mesure que les nettoyages progressent, vous pourrez balayer de plus en plus de code malveillant dans des bacs encapsulés.Ensuite, vous pourrez les sélectionner un par un à l’avenir.

Un outil comme javadoc ou doxygen, s'il n'est pas déjà utilisé, peut également contribuer à améliorer la documentation et la compréhensibilité du code.

Les arguments contre une réécriture complète sont assez forts.Ces tonnes de « petits bugs » et de comportements qui ont été codés au cours de la période du projet original réapparaîtront immédiatement.

Answer 3

Voir l'essai de Joel Spolsky Choses que vous ne devriez jamais faire.En résumé, lorsque vous réécrivez, vous perdez toutes les leçons que vous avez apprises pour que votre code actuel fonctionne comme il doit fonctionner.

Voir également: Grosse boule de boue

Answer 4

Il est rare qu’une réécriture de quelque chose de complexe réussisse.C'est tentant, mais c'est une stratégie à faible pourcentage.

Obtenez le code existant sous tests unitaires et refactorisez-le, et/ou remplacez-le complètement de petites parties de manière incrémentielle lorsque cela est opportun.

Answer 5

Refactorisez à moins que ce ne soit vraiment très mauvais.

Joël a beaucoup à dire à ce sujet...

À tout le moins, réécrivez le code avec l’ancien code devant vous et ne recommencez pas à zéro.L'ancien code est peut-être terrible, mais il en est ainsi pour une raison et si vous l'ignorez, vous finirez par voir les mêmes bogues qui ont probablement été corrigés il y a des années dans l'ancien code.

Answer 6

L'une des raisons pour lesquelles j'ai réécrit dans l'un de mes emplois précédents était l'incapacité de trouver des développeurs ayant suffisamment d'expérience pour travailler sur la base de code d'origine.

La décision a été prise de nettoyer d'abord la structure de la base de données sous-jacente, puis de la réécrire de manière à faciliter la recherche d'employés et/ou de sous-traitants à temps plein.

Je n'ai pas encore entendu comment ça s'est passé :)

Je pense que les gens ont tendance à opter pour des réécritures parce que cela semble plus amusant en surface.

Nous pouvons reconstruire à partir de zéro !

Nous le ferons correctement cette fois!

etc.

Answer 7

Il y a un nouveau livre qui sort, Développement d'applications Brownfield dans .NET par Baley et Belcham.Le premier chapitre est gratuit et aborde ces problèmes d’un point de vue essentiellement indépendant de la plate-forme.

Answer 8

Réparer, ou plus important encore, refactoriser.Les deux parce que Joël l'a dit et aussi parce que, s'il s'agit de votre code, vous avez probablement appris beaucoup plus de choses depuis que vous avez touché ce code pour la dernière fois.Si vous l'avez écrit dans .NET 1.1, vous pouvez le mettre à niveau vers la version 3.5 SP1.Vous pouvez entrer et purger tout l’ancien code commenté.Vous êtes 100 fois meilleur en tant que développeur maintenant que lorsque vous avez écrit ce code pour la première fois.

La seule exception, je pense, est lorsque le code utilise des technologies vraiment obsolètes - auquel cas vous pourriez être mieux servi en écrivant une nouvelle version.Si vous regardez une application VB6 avec 10 000 lignes de code avec un backend de base de données Access évidemment configuré par quelqu'un qui ne savait pas grand chose sur le fonctionnement des bases de données (ce qui pourrait très bien être vous il y a huit ans), alors vous pouvez probablement tirer une solution plus rapide basée sur C#/SQL en une fraction du temps et du code.

Answer 9

Ce n'est pas si noir ou blanc...cela dépend vraiment de beaucoup de facteurs (le plus important étant "qu'est-ce que la personne qui vous paie veut que vous fassiez")

Là où je travaille, nous avons réécrit un cadre de développement, et d'un autre côté, nous continuons à modifier certains anciens systèmes qui ne peuvent pas être migrés (en raison de la technologie du client et des contraintes de temps).Dans ce cas, nous essayons de conserver le style de codage et vous devez parfois implémenter de nombreuses solutions de contournement en raison de la façon dont il a été construit.

Answer 10

Selon votre situation, vous pourrait j'ai une autre option :code tiers sous licence.

J'ai consulté quelques entreprises où ce serait un choix judicieux, même si apparemment « jeter la propriété intellectuelle » peut constituer un obstacle majeur pour la direction.Dans mon entreprise actuelle, nous avons sérieusement envisagé l'option viable consistant à utiliser du code tiers pour remplacer notre framework principal, mais cette idée a finalement été rejetée davantage pour des raisons commerciales que techniques.

Pour répondre directement à votre question, nous avons finalement choisi de réécrire le framework existant - une décision que nous n'avons pas prise à la légère !14 mois plus tard, nous ne regrettons pas du tout ce choix.Rien qu’en considérant le temps passé à corriger les bugs, notre nouveau framework a presque été rentabilisé.Du côté négatif, les fonctionnalités ne sont pas encore complètes, nous sommes donc dans la position peu enviable de maintenir deux frameworks distincts en parallèle jusqu'à ce que nous puissions porter la dernière de nos applications "front-end".

Answer 11

Je recommande fortement de lire « Travailler efficacement avec le code hérité » de Michael Feathers.Il s'agit de conseils de coaching sur la façon de refactoriser votre code afin qu'il soit testable unitairement.