我确信你们都去过那里，你们开展了一个项目，那里有一个蹩脚的旧代码库，几乎不符合目的，你必须决定从头开始重新编写或修复什么已经存在。
传统智慧倾向于建议您不要尝试从头开始重写，因为失败的风险非常高。那么你在面对这个问题时做了什么，你是如何做出决定的？结果是什么？
答案 0 :(得分：10)
每次使用它时，只需稍微清理一下代码即可。如果还没有，请设置单元测试框架。所有新代码都应该编写测试。您因错误而修复的任何旧代码，也尝试在测试中滑动。
随着清理工作的进展，您将能够将越来越多的讨厌代码扫描到封装的容器中。然后你可以在将来逐一挑选这些。
像javadoc或doxygen这样的工具（如果尚未使用）也可以帮助改进代码文档和可理解性。
反对完全重写的论据非常强大。在原始项目的时间范围内编码的那些“小错误”和行为将再次潜入其中。
答案 1 :(得分：10)
这实际上取决于它有多糟糕。
如果它是一个小系统，并且你完全理解它，那么重写并不疯狂。
另一方面，如果它是一个巨大的遗留怪物，拥有一千万行无证的神秘代码，那么你真的很难完全重写。
要考虑的要点：
我会毫不犹豫地为一个大型系统承担一个巨大的重写项目而无法一次发布一个新版本。
答案 2 :(得分：5)
见Joel Spolsky的文章Things You Should Never Do。总而言之，当您重写时，您将失去所学到的所有课程，以使您当前的代码按照它需要的方式工作。
另请参阅：Big Ball of Mud
答案 3 :(得分：3)
很难重写任何复杂的东西才能成功。这很诱人，但是策略率很低。
在单元测试下获取遗留代码并重构它，和/或在适当的时候以增量方式完全替换它的一小部分。
答案 4 :(得分：2)
重构，除非确实非常糟糕。
Joel has a lot to say on this...
至少，用你面前的旧代码重写代码，不要只是从头开始。旧的代码可能很糟糕，但它是出于某种原因的方式，如果你忽略它，你最终会看到旧代码中可能修复的相同错误。
答案 5 :(得分：2)
在我之前的一份工作中重写的一个原因是无法找到具有足够经验的开发人员来处理原始代码库。
决定首先清理底层数据库结构，然后重写一些能够更容易找到全职员工和/或承包商的东西。
我还没有听说过它是如何实现的：）
我认为人们倾向于重写，因为表面看起来更有趣。
我们从头开始重建！
我们这次正确！
等
答案 6 :(得分：2)
Baley和Belcham正在出版一本新书Brownfield Application Development in .NET。第一章是免费的，从大多数平台无关的角度讨论这些问题。
答案 7 :(得分：2)
修复，或者更重要的是，重构。两者都是因为Joel said so而且因为，如果它是你的代码，你可能已经学到了很多东西，因为你最后触及了这个代码。如果您在.NET 1.1中编写它，则可以将其升级到3.5 SP1。你可以进入并清除所有旧的注释掉的代码。作为开发人员，您比第一次编写此代码时要好100倍。
我认为一个例外是当代码使用真正过时的技术时 - 在这种情况下，通过编写新版本可能会更好。如果您正在查看一些带有10,000行代码的VB6应用程序，而Access数据库后端显然是由一个对数据库工作原理不太了解的人（这可能是八年前的那个）知道的那么你可能会拉在很短的时间内完成基于C＃/ SQL的快速解决方案。
答案 8 :(得分：1)
它不是那么黑白......它真的取决于很多因素（更重要的是“付钱给你的人想要你做什么”）
在我工作的地方，我们重新编写了一个开发框架，另一方面，我们不断修改一些无法迁移的旧系统（因为客户端的技术和时间限制）。在这种情况下，我们尝试保留编码风格，有时你必须实现很多变通方法，因为它的构建方式
答案 9 :(得分：1)
根据您的具体情况，可能还有其他选项：许可证中的第三方代码。
我曾在几家公司咨询过这个明智的选择，虽然看似“扔掉IP”可能是管理层的一大障碍。在我现在的公司，我们认真考虑使用第三方代码替换我们的核心框架的可行选择，但由于商业原因而不是技术原因，这个想法最终被拒绝了。
为了直接回答你的问题，我们最终选择重写遗留框架 - 这个决定我们并没有掉以轻心！ 14个月后，我们不会后悔这个选择。考虑到修复错误所花费的时间，我们的新框架几乎为自己付出了代价。从消极方面来说，它还不是很完善，所以我们处于维护两个独立框架的不利位置，直到我们可以移植最后一个“前端”应用程序。
答案 10 :(得分：1)
我强烈建议阅读Michael Feathers的“有效使用遗留代码”。它是关于如何重构代码的指导建议，以便它可以进行单元测试。