如何从继承自CollectionBase的类重构泛型？

Question

我正在开发一个大约250,000行代码的应用程序。我目前是唯一一个开发此应用程序的开发人员，最初是在.NET 1.1中构建的。 Pervasive始终是一个继承自CollectionBase的类。所有数据库集合都继承自此类。我正在考虑重构从通用集合List继承。毋庸置疑，Martin Fowler的重构书没有任何建议。我应该尝试这个重构吗？如果是这样，解决这个重构的最佳方法是什么？

是的，整个都有单元测试，但没有QA团队。

Answer 1

别。除非你有一个非常好的商业理由通过这个练习来放置代码库。您的重构产生的成本节约或收入是多少？如果我是你的经理，我可能会建议不要这样做。抱歉。

Answer 2

如果您 要继续使用它，请不要使用列表＆lt; T＆gt; 。相反，使用System.Collections.ObjectModel.Collection< T >，它更像是CollectionBase的一个虚拟成功者。

Collection<T>类提供了受保护的方法，可用于在添加和删除项目，清除集合或设置现有项目的值时自定义其行为。如果您使用List<T>，则无法覆盖Add()方法，以便在有人向广告集合投放广告时进行处理。

Answer 3

CollectionBase是如何从继承的类中公开的？ Generics有没有比CollectionBase更好的东西？

我的意思是这个类被大量使用，但它只是一个类。重构的关键不在于扰乱计划的现状。班级应该始终与外界保持契约。如果你能做到这一点，你重构的代码不是25万行，但可能只有2500行（随机猜测，我不知道这个类有多大）。

但是如果这个课程有很多曝光，你可能不得不把这种曝光视为合同，并试图将曝光率排除在外。

Answer 4

250,000行很多都是重构的，而且你应该考虑以下几个：

1. 您是否有能够对重构代码进行质量保证的质量保证部门？
2. 您是否对旧代码进行了单元测试？
3. 项目周围是否有时间范围，即用户是否在查找错误时是否维护代码？

如果您回答1和2否，我首先要为现有代码编写单元测试。使它们广泛而彻底。一旦你有了这些，分支一个版本，并开始重构。单元测试应该能够帮助您正确地重构泛型。

如果2为是，那么只需分支并开始重构，依赖于那些单元测试。

质量保证部门也会提供很多帮助，因为您可以将新代码用于测试。

最后，如果客户/用户需要修复错误，请先修复它们。

Answer 5

我认为重构和保持代码更新是避免代码腐烂/嗅觉的一个非常重要的过程。许多开发人员要么与他们的代码结婚，要么在单元测试中没有足够的信心，能够将事情分开并清理干净并做得正确。

如果你没有花时间进行清理并使代码更好，那么从长远来看你会后悔，因为你必须在未来许多年内维护这些代码，否则接管代码的人将会恨你。你说你有单元测试，你应该能够相信这些测试，以确保当你重构代码时它仍然可以工作。

所以我说要做，清理它，让它美丽。如果您不确定您的单元测试可以处理重构，请再写一些。

Answer 6

我同意托马斯的观点。

我觉得你在重构时应该总是问自己这样一个问题：“通过这样做，我与自己的时间做些什么可以获得什么？”答案可能很多，从提高可维护性到提高性能，但总是以牺牲其他东西为代价。

没有看到代码，我很难说，但这听起来像是一个非常糟糕的情况需要重构。测试很好，但它们并非万无一失。所需要的只是其中一个人有一个错误的假设，你的重构可能会引入一个令人讨厌的错误。如果没有质量保证来抓住它，那就不会好了。

我个人对这样的大规模重构也有点兴奋。让我失业一次。这是我在政府之外的第一份工作（往往更宽容，一旦你获得'任期'，这很难被解雇）我是唯一的网络程序员。我有一个遗留的ASP应用程序，写得很糟糕。我的首要任务是将重新制作的东西重构为更少...... icky。我的雇主想要灭火，仅此而已。六个月后，我再次寻找工作：这个故事的道德：在开始这个之前先咨询你的经理。