我正在开发一个大约250,000行代码的应用程序。我是目前唯一在此应用程序中工作的开发人员，该应用程序最初是在.NET 1.1中构建的。普遍存在的是从CollectionBase继承的类。所有数据库集合都从此类继承。我正在考虑重构以从通用集合List继承。不用说，马丁·福勒的《重构》一书没有任何建议。我应该尝试这种重构吗？如果是这样，解决此重构的最佳方法是什么？

是的，整个过程中都有单元测试，但没有质量检查团队。

解决方案

别。除非我们有很好的商业理由要通过此练习放置代码库。重构带来的成本节省或者收益是多少？如果我是你的经理，我可能会建议不要这样做。对不起。

250,000行可重构，此外，我们还应考虑以下几个方面：

• 我们是否有QA部门能够对重构后的代码进行质量检查？
• 我们是否有旧代码的单元测试？
• 项目周围是否有时间表，即我们是否在用户发现错误时维护代码？

如果我们回答1和2否，那么我将首先为现有代码编写单元测试。使它们广泛而透彻。一旦有了这些，就分支一个版本，然后开始重构。单元测试应该能够正确地重构泛型。

如果2是，则仅分支并依靠这些单元测试开始重构。

质量检查部门也将提供很多帮助，因为我们可以向他们提供新代码以进行测试。

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

我同意托马斯的观点。

我觉得在重构时我们应该经常问自己一个问题："通过这样做与用时间做其他事情，我会得到什么？"答案可能是很多，从增加可维护性到更好的性能，但这总会以牺牲其他东西为代价。

没有看代码，我很难说出来，但这听起来很难重构。测试是好的，但并不是万无一失的。对于其中之一，我们所要做的只是一个错误的假设，重构可能会引入讨厌的错误。如果没有质量保证，那将是不好的。

我个人也有点像这样的大规模重构。花了我一次工作。这是我在政府以外的第一份工作(这往往有点宽容，一旦我们获得"任期"，就很难被解雇)，我是唯一的Web程序员。我有一个遗留的ASP应用程序，写得不好，丢在了我的腿上。我的首要任务是将织补的东西重构为更少的...恶臭的东西。我的雇主只想扑灭大火，仅此而已。六个月后，我又在找工作：p这个故事的寓意：在着手此事之前，请先咨询经理。

我认为重构和保持代码最新是避免代码腐烂/气味的非常重要的过程。许多开发人员或者受制于自己的代码，或者对单元测试不够自信，无法将其撕裂，清理干净并正确执行。

如果我们不花时间清理和改进代码，从长远来看，我们会后悔的，因为我们必须将代码维护很多年，否则谁接管了代码都会讨厌我们。我们说我们有单元测试，应该能够信任那些测试，以确保在重构​​代码时它仍然可以正常工作。

所以我说去做，清理它，使其美丽。如果我们不确定单元测试是否可以处理重构，请编写更多内容。

如果要使用它，请不要使用List <T>。而是使用System.Collections.ObjectModel.Collection <T>，它更像是CollectionBase的精巧继承者。

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

继承类的CollectionBase有多暴露？
有没有泛型可以比CollectionBase更好的东西？

我的意思是该课程被大量使用，但是它只是一个课程。重构的关键是不影响程序的现状。班级应始终保持与外界的合同。如果我们能做到这一点，那么我们重构的并不是代码行的25万行，而可能只有2500行(随机猜测，我不知道此类的大小)。

但是，如果此类中有很多风险敞口，则我们可能不得不将该风险敞口视为合同，并尝试将其排除在外。