Comment refactoriser des génériques à partir d'une classe héritée de CollectionBase?

Question

Je travaille sur une application d'environ 250 000 lignes de code. Je suis actuellement le seul développeur travaillant sur cette application qui a été construite à l'origine dans .NET 1.1. Pervasive est une classe qui hérite de CollectionBase. Toutes les collections de bases de données héritent de cette classe. J'envisage de refactoring pour hériter de la liste de collection générique à la place. Inutile de dire que le livre Refactoring de Martin Fowler n'a aucune suggestion. Devrais-je essayer ce refactor? Si oui, quelle est la meilleure façon d'aborder ce refactor?

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

Answer 1

250000 Lines est beaucoup à factoriser, plus vous devez prendre en compte plusieurs des suivants:

1. Avez-vous un service d'assurance qualité qui sera en mesure de contrôle qualité du code refondus?
2. Avez-vous des tests unitaires pour l'ancien code?
3. Y a-t-il une période autour du projet, c'est-à-dire que vous gérez le code lorsque les utilisateurs trouvent des bogues?

Si vous avez répondu 1 et 2 non, j'écrirais d'abord et avant tout des tests unitaires pour le code existant. Faites-les étendus et complets. Une fois que vous avez ceux en place, branchez une version et commencez le refactoring. Les tests unitaires devraient être en mesure de vous aider à refactoriser correctement les génériques.

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

Un département QA serait également très utile, puisque vous pouvez leur attribuer le nouveau code à tester. Et enfin, si les clients/utilisateurs ont besoin de corriger les bogues, corrigez-les d'abord.

Answer 2

Ne pas. Sauf si vous avez une très bonne justification commerciale pour mettre votre base de code à travers cet exercice. Quelles sont les économies de coûts ou les revenus générés par votre refactor? Si j'étais votre directeur je conseillerais probablement contre lui. Pardon.

Answer 3

Je suis d'accord avec Thomas.

Je pense que la question que vous devriez toujours vous poser lorsque vous refactorisez est: «Qu'est-ce que je gagne en faisant cela en faisant autre chose avec mon temps? La réponse peut être de nombreuses choses, de l'augmentation de la maintenabilité à une meilleure performance, mais cela se fera toujours au détriment de quelque chose d'autre.

Sans voir le code, c'est difficile à dire pour moi, mais cela semble être une très mauvaise situation à refactoriser. Les tests sont bons, mais ils ne sont pas infaillibles. Tout ce qu'il faut, c'est que l'un d'eux ait une mauvaise supposition, et votre refactor pourrait introduire un méchant bug. Et sans QA pour l'attraper, ce ne serait pas bon.

Je suis aussi personnellement un peu au courant des refacteurs massifs comme celui-ci. Ça m'a coûté un boulot une fois. C'était mon premier emploi à l'extérieur du gouvernement (ce qui tend à être un peu plus indulgent, une fois que vous avez obtenu la permanence, c'est dur à cuire) et j'étais le seul programmeur web. J'ai une application ASP héritée qui a été mal écrite sur mes genoux. Ma première priorité était de faire en sorte que la chose soit refaite en quelque chose de moins ... icky. Mon employeur voulait que les incendies soient éteints et rien de plus. Six mois plus tard, je cherchais du travail à nouveau: p Morale de cette histoire: Vérifiez d'abord avec votre manager avant de vous embarquer.

Answer 4

Je pense que le refactoring et la mise à jour de votre code sont un processus très important pour éviter la pourriture du code/l'odeur.Beaucoup de développeurs souffrent soit d'être mariés à leur code, soit de ne pas être assez confiants dans leurs tests unitaires pour être capables de déchirer les choses et de les nettoyer et de le 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 devrez conserver ce code pendant de nombreuses années, ou celui qui prend en charge le code Je vais te détester. Vous avez dit que vous avez des tests unitaires et que vous devriez pouvoir faire confiance à ces tests pour vous assurer que lorsque vous refactoriserez le code, cela fonctionnera toujours.

Alors, dis-le, nettoie-le, rends-le beau. Si vous n'êtes pas certain que vos tests unitaires peuvent gérer le refactor, écrivez-en d'autres.

Answer 5

Si vous sont va aller jusqu'au bout, ne pas utiliser Liste < T>. Au lieu de cela, utilisez System.Collections.ObjectModel.Collection< T >, qui est plus d'un succesor spirtual à CollectionBase.

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

Answer 6

Quelle est l'exposition de CollectionBase par rapport à la classe héritée?
Y a-t-il des choses que Generics pourrait faire mieux que CollectionBase?

Je veux dire que cette classe est très utilisée, mais ce n'est qu'une classe. La clé du refactoring 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 2500 (estimation aléatoire, 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 traiter cette exposition comme un contrat et essayer de minimiser l'exposition.