Je suis chargé de maintenir un système modestement volumineux (~ 60k LOC de non-Moose OO Perl). Je commence à remettre en question la sagesse de le refactoriser plutôt que de la réécriter. Je sais que cette question a été discutée longuement, mais la situation est inhabituellement complexe et a plusieurs éléments qui précèdent fortement dans des directions opposées, d'où ma question. Désolé pour la verbosité de la question; C'est aussi concis que je pouvais gérer tout en obtenant la photo entière à travers.
Au fur et à mesure que le système se trouve, les abstractions sont assez médiocres à encapsuler tout ce qui est proprement comme en témoigne de la confiance fréquente d'action à distance, d'une utilisation abondante des blocs if / autres avec une connaissance intime des objets d'un type non liés au module à la main, et un graphique de dépendance qui ressemble à un réseau social. Cela m'a senti mal, mais pourrait être refactored.
La couverture de test est poingty. Ceci est bien sûr fixable et doit être fixé avant le refacteur. Bien sûr, dans un système comme celui-là, des tests ont besoin d'une quantité absurde d'échafaudages, ce qui facilite l'amélioration de la couverture des tests plus ardue, mais toujours, il est difficilement impossible.
Et j'avais donc prévu de passer beaucoup de temps à apporter une certaine ordre au chaos. Je pensais durement, mais faisable, et le système fonctionne assez bien à des fins commerciales, malgré toutes ses questions, cela doit donc faire quelque chose de bien. Et "tout le monde sait" réécrire quelque chose comme ceci est une recette de catastrophe.
Mais récemment, j'ai découvert que certaines des parties les plus vitales et les plus écrites du système ont des erreurs de conception profondément assises et des erreurs de conception graves qui vont jusqu'au schéma de données. Toute la méthodologie a des problèmes majeurs (c'est un consensus entre ceux qui ont travaillé dessus, pas seulement moi) et les solutions de contournement pour cela constituent probablement la moitié du code dans cette partie, bien que cela soit mal écrit qu'il n'y ait aucun espoir de les distinguer de Logique commerciale. Le code est trop convolué pour moi-même (je ne travaille que depuis quelques mois) ou le responsable primaire précédent (de plusieurs années) de comprendre pleinement. Il a également une couverture de test inférieure à 10%.
Personne n'est convaincu qu'ils peuvent décrire complètement et correctement ce que cette partie accomplit, beaucoup moins comment. Obtenir une bonne couverture de test pour cette partie est tout sauf impossible lorsque le code est indéchiffrable et que les exigences qu'il se rencontrent ne sont pas bien comprises. Le refactoring sans la couverture des tests n'est pas correct, ni une pratique à distance dans un système de cette taille, de cette complexité, avec de tels problèmes de omission (et dactylographié de manière dynamique rend la découverte automatisée des impacts d'un changement impossible).
quitter cela et les coins sombres intacts ne sont pas une option en raison de l'évolution constante des exigences commerciales.
Le seul moyen pratique sur ceci que je peux voir commence par la nouvelle définition des exigences du système sur un niveau d'activité et de s'engager à respecter cette spécification et de risquer toute rupture que personne ne prévoyait. Je sais que c'est une mauvaise stratégie mais je ne vois pas d'alternative. Si cela est choisi comme trajet en avant, il semble que l'avantage du refactoring sort de la fenêtre, ce qui me laisse sérieusement remettre en question la vertu de même tenter de le refactoriser.
Cela me conduit à la question spécifique: refactore une mauvaise stratégie dans ce cas? Les réponses soutenues avec des expériences réelles sont fortement préférées, car je pense que les aspects théoriques sont bien établis ici et ailleurs.
3 Réponses :
Je suis actuellement dans la même position sur un projet, mais j'utilise quelques facteurs pour décider comment je devrais procéder; Espérons que ceux-ci seront d'une aide.
1) Mon principal critère est le projet déjà publié et nous maintenons un projet ou construisons-nous un projet qui va être libéré?
2) Combien de temps une réécriture prendra-t-elle? Le nouveau code vous réservera-t-il du temps sur la route dans la maintenance et le développement futur?
3) J'ai rencontré quelques pièces de logiciels trop lourdes qui sont trop goudronnées pour être refacturés et doivent simplement être réécrites pour que le logiciel puisse même travailler décemment.
Avec le projet, je travaille en ce moment, j'ai décidé fortement en faveur ou en refactoring, car nous sommes en train de développer et nous serons en mesure de libérer le projet au moins 3-4 mois plus tôt si nous n'avons pas 't faire une réécriture. Nous avons des projets de réécriture après sa publication, car la maintenance de ce logiciel sera un ours - elle n'est pas suffisamment optimisée ou suffisamment optimible pour gérer la quantité d'utilisateurs qu'il aura quelques mois après la publication du logiciel, Nous nous donnons quelques mois pour élaborer des bugs majeurs et ajouter quelques pièces supplémentaires au logiciel, puis nous allons commencer à travailler sur la réécriture.
Ainsi, espérons que mes 10 ¢ (2 ¢ + inflation) aide. Bonne chance!
été là, fait cela . Le code de la héritage que je maintienai actuellement est l'effort cumulatif de plusieurs personnes non-CS (ingénieurs) qui sont présentées pour obtenir leur programme pour atteindre les fonctionnalités requises à proximité de la maintenabilité, de la flexibilité ou de l'évolutivité.
Mais ce qui a fonctionné pour moi peut ne pas travailler pour tout le monde.
Dans de telles situations, il est souvent utile de répertorier tous les critères pertinents et de peser ses options. J'ai tendance à me poser les questions suivantes:
Il est trop facile de s'emporter avec la bonne chose, mais ne le faites que si vous avez l'adhésion de votre employeur.
mon expérience - Si l'entreprise ne voit pas la valeur dans la réécriture / refacteur, vous devez vraiment mettre cette activité sur le back-brûleur. Concentrez-vous sur la documentation du code existant et de mieux comprendre la manière dont le code fonctionne avant de tenter d'écrire / modifier / tester quoi que ce soit au fur et à mesure requis.
Combien de fois les nouvelles demandes de mises à jour / fonctionnalités seront ajoutées au code?
Les activités les plus souvent entreprises, plus votre cas devient forté pour un refacteur / réécriture.
mon expérience - il est parfois plus précieux pour l'entreprise que vous travaillez avec le code existant et appliquez des correctifs bien documentés avec des modifications minimales.
Le code devra effectuer une fonction x après n mois. Comment est-ce capable aujourd'hui?
Ceci est applicable si le développement est en cours. Regardez à long terme et voyez ce que le code doit pouvoir faire et comment cela pourrait répondre à ces besoins dans son état actuel.
mon expérience - refactoring ne coupe parfois pas la moutarde, car l'état actuel du code est grossièrement inadéquat
Combien de temps faut-il pour mettre en œuvre les modifications envisagées?
L'estimation doit inclure le temps nécessaire pour comprendre, documenter, mettre en œuvre, tester, valider et libérer vos modifications.
mon expérience - cela prend vraiment beaucoup plus de temps que l'on pourrait imaginer initialement, en particulier les tests et la validation.
Merci! Cela couvre beaucoup de grands points sur l'option "Ne rien faire" que je préférerais éviter, mais néanmoins être la meilleure et je pense que vous avez énuméré de bonnes raisons pour lesquelles.
@purposeamy: Je ne dis rien faire; Documenter ce code peut être la chose la plus précieuse que vous puissiez faire.
Par "ne rien faire", je voulais dire, n'essayez pas de le réparer. Sûrement un travail de documentation de «meilleur effort» de documentation de ce que nous pouvons aider, mais cela ne résoudra pas le pire du problème, ni même nous ne nous rapprochera de manière mesurable de le faire. Les parties que la plupart doivent être documentées sont limitrophes infaisables pour découvrir et documenter complètement, d'où mon dilemme.
Premier, read Cet article sur pourquoi ne pas réécrire de Joel Spolsky. Ensuite, je suggère de vous concentrer sur les tests d'écriture, qui seront nécessaires pour la réécriture, le refacteur ou la maintenance normale. Une fois que cela est fait, Revisit Rewrite / Refactor Question.
J'ai lu cela et d'accord avec le principe, c'est pourquoi je trouve la décision de réécrire (ou de vivre avec elle plus ou moins telle qu'elle est difficile à accepter. Cependant, étant donné à la manière dont les problèmes interagissent, je suis douteux que, à une solution purement technique, comme le refactoring, c'est une solution réalisable ici.
Le grand drapeau rouge dans c'est ... vous ne savez pas vraiment ce que le code fait! Vous devez sûrement aller au point où vous avez compris et documenté le code avant de pouvoir vraiment envisager d'aller de l'avant?
+1: Je pense que c'est une excellente question. Je ne sais pas pourquoi certains pensent qu'il est trop localisé car ce poste pourrait fournir d'excellentes conseils pour les autres dans le même bateau.