我正在开发一个大约 250,000 行代码的应用程序。我目前是唯一一个开发这个最初在 .NET 1.1 中构建的应用程序的开发人员。Pervasive through 是一个继承自 CollectionBase 的类。所有数据库集合都继承自此类。我正在考虑重构以从通用集合 List 继承。不用说，Martin Fowler 的重构书没有任何建议。我应该尝试这个重构吗？如果是这样，解决此重构的最佳方法是什么？
是的，自始至终都有单元测试，但没有 QA 团队。
问问题
1364 次
6 回答
2
不。除非你有一个非常好的商业理由来让你的代码库通过这个练习。您的重构所节省的成本或收入是多少？如果我是你的经理，我可能会建议不要这样做。对不起。
于 2008-09-19T00:53:34.297 回答
2
如果您要完成它，请不要使用List< T >。相反，请使用System.Collections.ObjectModel。Collection< T >，它更像是 CollectionBase 的精神继承者。
该类Collection<T>提供了受保护的方法，可用于在添加和删除项目、清除集合或设置现有项目的值时自定义其行为。如果您使用List<T>没有办法覆盖Add()当有人向集合投放广告时处理的方法。
于 2008-09-19T04:09:47.650 回答
2
CollectionBase 从继承的类中暴露的程度如何？
泛型能比 CollectionBase 做得更好吗？
我的意思是这个类被大量使用，但它只是一个类。重构的关键是不扰乱程序的现状。该类应始终保持与外部世界的契约。如果你能做到这一点，你重构的代码不是 25 万行，而可能只有 2500 行（随机猜测，我不知道这个类有多大）。
但是，如果这门课有很多曝光，您可能不得不将该曝光视为合同，并尝试将曝光排除在外。
于 2008-09-19T04:32:38.687 回答
1
250,000 行需要重构很多，另外你应该考虑以下几个：
- 你有一个 QA 部门可以对重构的代码进行 QA 吗？
- 你有旧代码的单元测试吗？
- 是否有围绕项目的时间表，即您是否在用户发现错误时维护代码？
如果您回答 1 和 2 否，我将首先为现有代码编写单元测试。使它们广泛而彻底。一旦你有了这些，分支一个版本，然后开始重构。单元测试应该能够帮助您正确地重构泛型。
如果 2 是肯定的，那么就根据这些单元测试进行分支并开始重构。
QA 部门也会有很大帮助，因为您可以将新代码提交给他们进行测试。
最后，如果客户/用户需要修复错误，请先修复它们。
于 2008-09-19T00:54:01.910 回答
1
我认为重构和保持代码最新是避免代码腐烂/异味的一个非常重要的过程。许多开发人员要么与他们的代码结婚，要么对他们的单元测试缺乏足够的信心，无法将事情拆开并清理干净并正确执行。
如果你不花时间清理它并使代码变得更好，那么从长远来看你会后悔的，因为你必须在未来的许多年里维护那个代码，否则谁会讨厌你。你说你有单元测试，你应该能够信任这些测试，以确保当你重构代码时它仍然可以工作。
所以我说做吧，把它清理干净，让它变得漂亮。如果您不确定您的单元测试可以处理重构，请多写一些。
于 2008-09-19T04:05:27.083 回答
0
我同意托马斯的观点。
我觉得在重构时你应该经常问自己的问题是“做这件事和用我的时间做其他事情我能得到什么？” 答案可以是很多东西，从提高可维护性到更好的性能，但它总是以牺牲其他东西为代价。
如果没有看到代码，我很难判断，但这听起来是一个非常糟糕的重构情况。测试是好的，但它们不是万无一失的。只需要其中一个做出错误的假设，您的重构可能会引入一个令人讨厌的错误。如果没有 QA 来捕捉它，那就不好了。
我个人也对像这样的大规模重构有点担心。曾经让我失去了一份工作。这是我在政府之外的第一份工作（这往往更宽容一点，一旦你获得“终身职位”就很难被解雇），我是唯一的网络程序员。我得到了一个写得很糟糕的遗留 ASP 应用程序，落在了我的腿上。我的首要任务是将这该死的东西重构为不那么...恶心的东西。我的雇主希望把火扑灭，仅此而已。六个月后，我又开始找工作了：p 这个故事的寓意：在开始之前先咨询你的经理。
于 2008-09-19T03:54:48.137 回答