Rewrite or repair?我敢肯定，您到过那里，都在一个项目中，那里有一个破旧的旧代码库，几乎不能满足目的，您必须决定从头开始重写它或修复已经存在的代码。 传统观点倾向于建议您不要尝试从头开始重写，因为失败的风险非常高。 那么，面对这个问题，您做了什么？您是如何做出决定的？结果如何？ 这实际上取决于它的严重程度。 如果它是一个小型系统，并且您完全理解它，那么重写并不疯狂。 另一方面，如果它是一个巨大的遗留怪物，具有一千万行未记录的神秘代码，那么您将很难完全重写。 要考虑的要点：
我真的很犹豫是否要承担大型系统的大型改写项目，而又不能一次发行一个新版本。 每次使用它时，只需清理一下代码即可。如果还没有，请设置一个单元测试框架。所有新代码都应编写测试。由于错误而修复的所有旧代码，也请尝试插入测试。 随着清理的进行，您将能够将越来越多的讨厌代码扫入封装的垃圾箱中。然后，您可以将来一一挑选。 诸如javadoc或doxygen之类的工具(如果尚未使用)也可以帮助改善代码文档和可理解性。 反对完全重写的论点很强。在原始项目的时间范围内编码的大量"小错误"和行为将再次潜入。 请参阅Joel Spolsky的文章"您不应该做的事情"。总而言之，当您进行重写时，您将失去为使当前代码按需要的工作方式而学到的所有课程。 另请参阅：泥浆大球 很难成功重写任何复杂的东西。这很诱人，但是比例策略很低。 在单元测试下获取遗留代码并对其进行重构，和/或在适当时逐步增量替换其一小部分。 修复或更重要的是重构。这既是因为Joel这么说，也是因为，如果这是您的代码，自从您上次触摸此代码以来，您可能已经学到了很多东西。如果是在.NET 1.1中编写的，则可以将其升级到3.5 SP1。您可以进入并清除所有旧的注释掉的代码。与最初编写此代码时相比，您现在作为开发人员要好100倍。 我认为一个例外是，当代码使用真正过时的技术时，在这种情况下，编写新版本可能会更好。如果您正在查看带有10,000行代码且带有Access数据库后端的某些VB6应用程序，显然是由对数据库的工作原理不了解的人(很可能是八年前)设置的，那么您可能可以在短短的时间和代码中获得了一种基于C＃/ SQL的更快解决方案。 有新书问世，Baley和Belcham撰写了.NET中的Brownfield应用程序开发。第一章是免费的，主要从平台不可知的角度讨论这些问题。 在我以前的工作之一上进行重写的原因之一是无法找到具有足够经验的开发人员来处理原始代码库。 决定首先清理基础数据库结构，然后重写某些内容，以便更轻松地找到全职员工和/或承包商。 我还没有听说它是如何工作的:) 我认为人们倾向于重写，因为表面上看起来更有趣。 我们从头开始重建！ 这次我们会做的正确！ 等等 重构，除非确实非常糟糕。 乔尔对此有很多话要说... 至少，用您面前的旧代码重写代码，而不仅仅是从头开始。旧代码可能很糟糕，但这是出于某种原因的方式，如果您忽略它，最终将看到与几年前旧代码中已修复的错误相同的错误。 我强烈建议阅读Michael Feathers撰写的"有效使用旧版代码"。它是有关如何重构代码以使其可进行单元测试的教练建议。 根据您的情况，您可能还有其他选择：许可内第三方代码。 我曾在几家公司咨询过，虽然似乎"扔掉IP"可能是管理的一大障碍，但这是明智的选择。在我目前的公司中，我们认真考虑了使用第三方代码代替我们的核心框架的可行选择，但最终该想法最终由于业务原因而不是技术原因而被拒绝。 为了直接回答您的问题，我们最终选择了重写旧框架-我们没有轻易做出这个决定！ 14个月后，我们完全不后悔这个选择。仅考虑花费在修复错误上的时间，我们的新框架几乎已经收回了成本。不利的一面是，它还不是很完整的功能，因此我们无法并行维护两个单独的框架，直到可以移植最后一个"前端"应用程序为止。 它不是那么黑白...实际上取决于很多因素(更重要的是"付钱给您的人想要您做什么") 在我工作的地方，我们重新编写了开发框架，另一方面，我们不断修改一些无法迁移的旧系统(由于客户端的技术和时间限制)。在这种情况下，我们尝试保留编码风格，有时由于其构建方式，您必须实现许多变通方法 |
