Quand est-il bon (si jamais) de supprimer le code de production et de recommencer?

Question

On m'a demandé de faire une revue de code et de faire rapport sur la faisabilité de l'ajout d'une nouvelle fonctionnalité pour l'un de nos nouveaux produits, un que je n'ai pas personnellement travaillé jusqu'à maintenant. Je sais que c'est facile à pinailler quelqu'un d'autre code, mais je dirais qu'il est en mauvais état (tout en essayant d'être aussi objectif que possible). Quelques faits saillants de mon examen de code:

• L'abus de threads: QueueUserWorkItem le nombre de threads et, en général, sont utilisés beaucoup, et le Thread du pool des délégués ont sans valeur informative des noms tels que PoolStart et PoolStart2. Il y a aussi un manque de synchronisation entre les threads, en particulier d'accéder aux objets de l'INTERFACE utilisateur sur les threads autre que le thread d'INTERFACE utilisateur.

• Des numéros de magie et de la magie des cordes: Quelques Consts et Enums'sont définis dans le code, mais le code s'appuie sur des valeurs littérales.

• Les variables globales: de Nombreuses variables sont déclarées mondiale et peut ou ne peut pas être initialisé en fonction de ce que les chemins de code obtenir de suivi et de quel ordre les choses se produire dans. Cela devient très déroutant lorsque le code est également sauter partout entre les threads.

• Les avertissements du compilateur: Le principal fichier de solution contient plus de 500 mises en garde, et le nombre total est inconnu pour moi. J'ai reçu un avertissement à partir de Visual Studio qu'il ne pouvait pas afficher plus de mises en garde.

• Demi-fini de classes: Le code a été travaillé et a ajouté ici et là, et je pense que cela conduit à des gens oublient ce qu'ils avaient fait avant, donc il y a un peu apparemment à moitié fini de classes et de vide talons.

• Pas Inventé Ici: Le produit doublons fonctionnalité qui existe déjà en commun des bibliothèques utilisées par d'autres produits, tels que l'accès aux données les aides, la journalisation des erreurs des aides, et de l'interface utilisateur des aides.

• La séparation des préoccupations: je pense que quelqu'un tenait le livre à l'envers quand ils ont lu sur le typique "de l'INTERFACE utilisateur -> calque -> couche d'accès aux données" architecture 3 tiers. Dans ce code, la couche d'INTERFACE utilisateur accède directement à la base de données, parce que la couche est partiellement mis en œuvre, mais souvent ignorés en raison de ne pas matérialiser pleinement suffisant, et la couche d'accès aux données des contrôles de la couche d'INTERFACE utilisateur. La plupart du faible niveau de la base de données et du réseau des méthodes fonctionnent sur une référence mondiale dans le formulaire principal, et directement afficher, masquer, et de modifier la forme. Où plutôt mince couche de gestion est effectivement utilisé, il tend aussi à contrôler l'INTERFACE directement. La plupart de ce code de bas niveau utilise également MessageBox.Show afficher les messages d'erreur lorsqu'une exception se produit, et la plupart d'avaler l'exception d'origine. Bien sûr, cela rend un peu plus compliqué pour commencer à écrire des unités de tests pour vérifier la fonctionnalité du programme avant de tenter de refactoriser le code.

Je suis juste à gratter la surface, mais ma question est assez simple: Serait-il plus logique de prendre le temps de revoir la base de code existante, en se concentrant sur un problème à la fois, ou envisagez-vous de réécrire la totalité de la chose à partir de zéro?

EDIT: Pour préciser un peu, nous avons les exigences initiales du projet, c'est pourquoi de départ pourrait être une option. Une autre façon de formuler ma question est: Peut-code jamais atteindre un point où le coût de l'entretien qu'il allait devenir plus grande que le prix de dumping et de recommencer?

Answer 1

Sans aucun délit prévu, la décision de réécrire une base de code à partir de zéro est une commune, et la gestion sérieuse erreur de débutant, les développeurs de logiciel faire.

Il ya de nombreux inconvénients à se méfier.

• Réécritures d'arrêter les nouvelles fonctionnalités de froid pendant des mois ou des années. Peu de sociétés peuvent se permettre de rester encore pour longtemps.
• La plupart des plannings de développement sont difficiles à ongles. Cette réécriture ne fera pas exception. Amplifier le point précédent, maintenant, un retard dans le développement.
• Des Bugs qui ont été corrigés dans la base de code existante à travers l'expérience douloureuse sera présenté à nouveau. Joel Spolsky a d'autres exemples dans cet article.
• Danger de chute de la victime à la Seconde-effet sur le système -- en résumé, `les Gens qui ont conçu quelque chose qu'une fois avant d'essayer de faire toutes les choses qu'ils "ne pas faire la dernière fois", le chargement du projet avec toutes les choses qu'ils mettent hors tension tout en faisant de la version, même si la plupart d'entre eux doivent être mis hors tension en version deux."
• Une fois cette onéreuse réécriture est terminée, le très à côté de l'équipe d'hériter de la nouvelle base de code est susceptible d'utiliser les mêmes excuses pour faire une autre réécriture. Les programmeurs de la haine de l'apprentissage de quelqu'un d'autre code. Personne n'écrit parfait de code parce que la perfection est tellement subjectif. Trouvez-moi tout d'applications du monde réel et je peux vous donner un réquisitoire accablant et la justification de faire un à partir de zéro de réécriture.

Si vous finalement de réécriture à partir de zéro ou pas, le début d'une phase de refactoring est maintenant un bon moyen à la fois de réellement s'asseoir et de comprendre le problème, de sorte que la réécriture se fera plus en douceur si vraiment, en tant que bien que donner de la base de code existante un regard honnête pour vraiment voir si une réécriture est nécessaire.

Answer 2

Effectivement les rebuts et recommencer?

Lorsque le code actuel ne fait pas ce que vous voulez faire, et serait d'un coût prohibitif pour le changement.

Je suis sûr que quelqu'un va maintenant lien de Joel article sur Netscape lancer leur code et comment il est oh-so-terrible et une énorme erreur. Je ne veux pas en parler en détail, mais si vous n'lien de l'article, avant de le faire, pensez à ceci: l'IE moteur, le moteur qui a permis à MME de libérer IE 4, 5, 5.5 et 6 en succession rapide, le IE moteur qui a totalement détruit Netscape... c'était nouveau. Trident est un nouveau moteur après, ils en ont jeté l'IE 3 moteur parce qu'il ne fournit pas une base appropriée pour leur travail de développement. MS n'a que Joel a dit que vous ne devez jamais faire, et c'est parce que MS n'a donc qu'ils avaient un navigateur qui leur a permis de complètement eclipse Netscape. Donc, s'il vous plaît... tout simplement méditer sur cette pensée pour un moment avant de vous lien Joel et dire: "oh, vous ne devriez jamais le faire, c'est une idée terrible".

Answer 3

Si elle nécessite plus de temps pour lire et comprendre le code (si c'est encore possible) qu'il serait à réécrire l'ensemble de l'application, je dis de la ferraille et recommencer.

Être très prudent avec ce:

1. Êtes-vous sûr que vous n'êtes pas juste d'être paresseux et de ne pas prendre la peine de lire le code
2. Êtes-vous être arrogant sur le code qui vous permettra d'écrire par rapport à la ordures personne d'autre produit.
3. Rappelez-vous testé-code de travail est beaucoup plus de valeur qu'imaginaire encore-à-être-écrit le code

Dans les mots de notre estemed hôte et suzerain, Joel - des choses que vous ne devriez jamais faire,
il n'est pas toujours tort d'abandonner code du travail - mais vous devez être sûr de la raison.

Answer 4

Une règle d'or que j'ai trouvé utile, c'est que, si, étant donné une base de code, si j'ai ré-écrire plus de 25% du code pour le faire fonctionner ou de le modifier basée sur les nouvelles exigences, vous pouvez aussi bien le ré-écrire à partir de zéro.

Le raisonnement est que vous ne pouvez patch un corps de code jusqu'à présent; au-delà d'un certain point, c'est plus rapide à faire.

Il y a une hypothèse sous-jacente que vous avez un mécanisme (tels que le sérieux de l'unité et/ou des tests de système) qui vous dira si votre version remaniée est fonctionnellement équivalent (là où il faut) que l'original.

Answer 5

J'ai vu d'une demande de ré-architecturé dans les 2 ans de son introduction dans la production, et d'autres réécrit dans différentes technologies (l'un était en C++ - maintenant, Java). Tous ces efforts ont été n'ont pas été, à mon avis, un succès.

Je préfère une approche plus évolutive pour le mauvais logiciel. Si vous pouvez grouper vos anciens application telle que vous pouvez présenter à vos nouvelles exigences et de l'interface avec l'ancien code, vous pouvez aider vous-même dans le nouvel environnement sans avoir à "vendre" la valeur zéro (à partir d'un biz point de vue) de l'investissement dans la réécriture.

Approche suggérée - écrire des tests unitaires pour la fonctionnalité à laquelle vous souhaitez interface 1) s'assurer que le code se comporte comme prévu et 2) de fournir un filet de sécurité pour toute la refactorisation que vous pouvez faire sur l'ancienne base.

Mauvais code est la norme. Je pense qu'IL obtient une mauvaise réputation d'entreprise pour favoriser réécrit/rearchitecting/etc. Ils paient de l'argent et de la "confiance" (comme une industrie) afin d'offrir solide, extensible code. Malheureusement, les pressions aboutissent souvent à des raccourcis que rendre le code difficile à maintenir. Il est parfois de mauvais programmeurs... parfois de mauvaises situations.

Pour répondre à votre reformulé la question... peut-code des coûts de maintenance jamais dépasser la réécriture des coûts... la réponse est clairement oui. Je ne vois rien dans vos exemples, cependant, qui m'a conduit à croire que c'est votre cas. Je pense que ces questions peuvent être abordées avec les tests et le refactoring.