如何从继承自 CollectionBase 的类重构为泛型?
-
01-07-2019 - |
题
我正在开发一个大约有 250,000 行代码的应用程序。我是目前唯一一位致力于此应用程序的开发人员,该应用程序最初是在 .NET 1.1 中构建的。贯穿始终的是一个继承自CollectionBase的类。所有数据库集合都继承自此类。我正在考虑重构以从通用集合列表继承。不用说,Martin Fowler 的《重构》一书中没有任何建议。我应该尝试这个重构吗?如果是这样,解决此重构的最佳方法是什么?
是的,整个过程都有单元测试,但没有 QA 团队。
解决方案
250,000 行需要重构很多,而且您应该考虑以下几项:
- 您是否有 QA 部门能够对重构的代码进行 QA?
- 您对旧代码有单元测试吗?
- 项目是否有一个时间表,即当用户发现错误时,您是否正在维护代码?
如果您回答 1 和 2 否,我首先会为现有代码编写单元测试。使它们广泛而彻底。一旦这些准备就绪,就可以分支一个版本,然后开始重构。单元测试应该能够帮助您正确重构泛型。
如果 2 是肯定的,那么只需分支并开始重构,依赖于这些单元测试。
质量保证部门也会有很大帮助,因为您可以向他们提供新代码进行测试。
最后,如果客户/用户需要修复错误,请先修复它们。
其他提示
不。除非您有非常好的业务理由让您的代码库完成此练习。您的重构节省了多少成本或产生了多少收入?如果我是你的经理,我可能会建议反对。对不起。
CollectionBase 从继承类中暴露出来的程度如何?
泛型是否可以在某些方面比 CollectionBase 做得更好?
我的意思是这个类被大量使用,但它只是一个类。重构的关键是不扰乱程序的现状。班级应该始终保持与外界的契约。如果你能做到这一点,你重构的代码就不是25万行,而可能只有2500行(随机猜测,我不知道这个类有多大)。
但是,如果此类存在大量风险,您可能必须将该风险视为合同,并尝试将风险分解出来。
如果你 是 会经历它,不要使用 列表<T>. 。相反,使用 系统.集合.对象模型。收藏<T>, ,它更像是 CollectionBase 的精神继承者。
这 Collection<T>
类提供受保护的方法,可用于在添加和删除项目、清除集合或设置现有项目的值时自定义其行为。如果你使用 List<T>
没有办法覆盖 Add()
当有人向集合发布广告时处理的方法。
我认为重构并保持代码最新是避免代码腐烂/异味的一个非常重要的过程。许多开发人员要么与他们的代码结合在一起,要么对他们的单元测试缺乏足够的信心,无法将事情分解、清理并正确执行。
如果你不花时间清理它并使代码变得更好,从长远来看你会后悔的,因为你必须在未来的很多年里维护该代码,否则接管代码的人都会恨你。您说您有单元测试,并且您应该能够信任这些测试,以确保当您重构代码时它仍然可以工作。
所以我说去做吧,清理它,让它变得美丽。如果您不确定您的单元测试可以处理重构,请多写一些。
我同意托马斯的观点。
我觉得问题时您应该总是问自己,当重构是“我通过做其他时间来做些什么?”答案可以是很多事情,从提高可维护性到更好的性能,但它总是以其他事情为代价。
如果没有看到代码,我很难判断,但这听起来是一个非常糟糕的重构情况。测试固然很好,但也并非万无一失。所需要的只是其中一个有一个错误的假设,你的重构可能会引入一个讨厌的错误。如果没有 QA 来捕捉它,那就不好了。
我个人也对这样的大规模重构有点担心。有一次让我失去了工作。这是我在政府之外的第一份工作(政府往往更宽容一点,一旦你获得“终身职位”,就很难被解雇),而且我是唯一的网络程序员。我得到了一个写得不好的遗留 ASP 应用程序。我的首要任务是把这该死的东西重构成不那么……恶心的东西。我的雇主只想把火扑灭,仅此而已。六个月后,我再次找工作:p 这个故事的寓意是:在开始之前先咨询你的经理。