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

Question

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

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

Answer 1

250,000 行需要重构很多，而且您应该考虑以下几项：

1. 您是否有 QA 部门能够对重构的代码进行 QA？
2. 您对旧代码有单元测试吗？
3. 项目是否有一个时间表，即当用户发现错误时，您是否正在维护代码？

如果您回答 1 和 2 否，我首先会为现有代码编写单元测试。使它们广泛而彻底。一旦这些准备就绪，就可以分支一个版本，然后开始重构。单元测试应该能够帮助您正确重构泛型。

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

质量保证部门也会有很大帮助，因为您可以向他们提供新代码进行测试。

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

Answer 2

不。除非您有非常好的业务理由让您的代码库完成此练习。您的重构节省了多少成本或产生了多少收入？如果我是你的经理，我可能会建议反对。对不起。

Answer 3

CollectionBase 从继承类中暴露出来的程度如何？
泛型是否可以在某些方面比 CollectionBase 做得更好？

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

但是，如果此类存在大量风险，您可能必须将该风险视为合同，并尝试将风险分解出来。

Answer 4

如果你 是 会经历它，不要使用 列表<T>. 。相反，使用 系统.集合.对象模型。收藏<T>, ，它更像是 CollectionBase 的精神继承者。

这 Collection<T> 类提供受保护的方法，可用于在添加和删除项目、清除集合或设置现有项目的值时自定义其行为。如果你使用 List<T> 没有办法覆盖 Add() 当有人向集合发布广告时处理的方法。

Answer 5

我认为重构并保持代码最新是避免代码腐烂/异味的一个非常重要的过程。许多开发人员要么与他们的代码结合在一起，要么对他们的单元测试缺乏足够的信心，无法将事情分解、清理并正确执行。

如果你不花时间清理它并使代码变得更好，从长远来看你会后悔的，因为你必须在未来的很多年里维护该代码，否则接管代码的人都会恨你。您说您有单元测试，并且您应该能够信任这些测试，以确保当您重构代码时它仍然可以工作。

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

Answer 6

我同意托马斯的观点。

我觉得问题时您应该总是问自己，当重构是“我通过做其他时间来做些什么？”答案可以是很多事情，从提高可维护性到更好的性能，但它总是以其他事情为代价。

如果没有看到代码，我很难判断，但这听起来是一个非常糟糕的重构情况。测试固然很好，但也并非万无一失。所需要的只是其中一个有一个错误的假设，你的重构可能会引入一个讨厌的错误。如果没有 QA 来捕捉它，那就不好了。

我个人也对这样的大规模重构有点担心。有一次让我失去了工作。这是我在政府之外的第一份工作（政府往往更宽容一点，一旦你获得“终身职位”，就很难被解雇），而且我是唯一的网络程序员。我得到了一个写得不好的遗留 ASP 应用程序。我的首要任务是把这该死的东西重构成不那么……恶心的东西。我的雇主只想把火扑灭，仅此而已。六个月后，我再次找工作:p 这个故事的寓意是：在开始之前先咨询你的经理。