Comment refactoriser les génériques de la classe qui hérite de CollectionBase?

Question

Je travaille sur une application qui compte environ 250 000 lignes de code. Je suis actuellement le seul développeur travaillant sur cette application qui a été initialement créée dans .NET 1.1. Pervasive est une classe héritée de CollectionBase. Toutes les collections de bases de données héritent de cette classe. J'envisage plutôt de refactoriser pour hériter de la liste de collection générique. Inutile de dire que le livre de Refactoring de Martin Fowler n'a aucune suggestion. Devrais-je essayer ce refactor? Si oui, quel est le meilleur moyen de s’attaquer à ce refactor?

Et oui, il y a des tests unitaires, mais aucune équipe d'assurance qualité.

Answer 1

250 000 lignes est beaucoup à refactoriser, plus vous devriez prendre en compte plusieurs des éléments suivants:

1. Avez-vous un service d'assurance qualité capable de contrôler le code refactorisé?
2. Avez-vous des tests unitaires pour l'ancien code?
3. Le projet comporte-t-il un calendrier, c’est-à-dire que vous conservez le code pendant que les utilisateurs trouvent des bogues?

si vous avez répondu 1 et 2 non, je voudrais avant tout écrire des tests unitaires pour le code existant. Faites-en une vaste et approfondie. Une fois ceux-ci en place, branchez une version et lancez le refactoring. Les tests unitaires devraient pouvoir vous aider à reformuler correctement les génériques.

Si 2 est oui, branchez simplement et commencez le refactoring, en vous basant sur ces tests unitaires.

Un service d'assurance de la qualité aiderait également beaucoup, car vous pouvez leur fournir le nouveau code à tester.

Enfin, si les clients / utilisateurs ont besoin de corrections de bugs, corrigez-les d'abord.

Answer 2

Ne pas. À moins que vous n’ayez une très bonne justification commerciale pour soumettre votre base de code à cet exercice. Quelles sont les économies de coûts ou les revenus générés par votre refactor? Si j'étais votre manager, je le déconseillerais probablement. Pardon.

Answer 3

À quel point CollectionBase est-il exposé à la classe héritée?
Y a-t-il des choses que les génériques pourraient faire mieux que CollectionBase?

Je veux dire que cette classe est très utilisée, mais ce n’est qu’une classe. La clé de la refactorisation ne perturbe pas le statu quo du programme. La classe devrait toujours maintenir son contrat avec le monde extérieur. Si vous pouvez le faire, ce n'est pas un quart de million de lignes de code que vous refactorisez, mais peut-être seulement 2 500 (au hasard, je n'ai aucune idée de la taille de cette classe).

Mais s'il y a beaucoup d'exposition de cette classe, vous devrez peut-être plutôt traiter cette exposition comme un contrat et essayer de factoriser l'exposition.

Answer 4

Si vous souhaitez l'exécuter, n'utilisez pas la Liste < T & Gt; . Utilisez plutôt System.Collections.ObjectModel. Collection & Lt; T & Gt; , qui est plutôt un successeur spirituel de CollectionBase.

La classe Collection<T> fournit des méthodes protégées qui peuvent être utilisées pour personnaliser son comportement lors de l'ajout et de la suppression d'éléments, de la suppression de la collection ou de la définition de la valeur d'un élément existant. Si vous utilisez List<T>, il n’existera aucun moyen de remplacer la méthode Add() à gérer lorsque des annonces sont diffusées dans la collection.

Answer 5

Je pense que le refactoring et la mise à jour de votre code sont des processus très importants pour éviter la pourriture / odeur de code. Beaucoup de développeurs souffrent d'être mariés à leur code ou simplement pas suffisamment confiants dans leurs tests unitaires pour être capables de déchirer des choses, de les nettoyer et de les faire correctement.

Si vous ne prenez pas le temps de le nettoyer et d'améliorer le code, vous le regretterez à long terme, car vous devez conserver ce code pendant de nombreuses années, sinon celui qui en prendra le contrôle vous déteste. Vous avez dit que vous disposiez de tests unitaires et que vous devriez pouvoir faire confiance à ces tests pour vous assurer que lorsque vous refacturerez le code, il fonctionnera toujours.

Je dis donc: faites-le, nettoyez-le, rendez-le beau. Si vous n'êtes pas sûr que vos tests unitaires peuvent gérer le refactor, écrivez-en davantage.

Answer 6

Je suis d'accord avec Thomas.

Je pense que la question que vous devriez toujours vous poser lorsque la refactorisation est & "Qu'est-ce que je gagne à faire cela par rapport à autre chose avec mon temps? &"; La solution peut être variée, de la facilité de maintenance à la performance, mais cela se fera toujours au détriment d’autre chose.

Sans voir le code, j'ai du mal à vous le dire, mais cela ressemble à une très mauvaise situation dans laquelle effectuer une refactorisation. Les tests sont bons, mais ils ne sont pas à l'abri de la faute. Tout ce qu’il faut, c’est que l’un d’eux ait une mauvaise supposition, et votre refactor pourrait introduire un méchant virus. Et sans assurance qualité, ce ne serait pas bon.

Personnellement, je suis aussi un peu au courant des refactors massifs comme celui-ci. M'a coûté un travail une fois. C'était mon premier emploi en dehors du gouvernement (ce qui a tendance à être un peu plus indulgent, une fois que vous avez obtenu le mandat, il est sacrément difficile de vous faire virer) et j'étais le seul programmeur Web. J'ai eu une ancienne application ASP mal écrite qui a été posée sur mes genoux. Ma première priorité était de faire en sorte que la moindre chose soit refactorisée en quelque chose de moins… méchant. Mon employeur voulait que les incendies soient éteints et rien de plus. Six mois plus tard, je cherchais encore du travail: p Morale de cette histoire: renseignez-vous auprès de votre responsable avant de vous lancer dans cette aventure.