【发布时间】：2010-09-07 07:21:36
【问题描述】：
我敢肯定，你们都去过那里，你们承担了一个项目，其中有一个破旧的代码库，几乎不能满足目的，你必须决定要么从头开始重新编写它，要么修复什么已经存在。
传统观点倾向于建议您永远不要尝试从头开始重写，因为失败的风险非常高。那么当你遇到这个问题时你是怎么做的，你是如何做出决定的，结果如何呢？
【问题讨论】：
标签： refactoring rewrite
【发布时间】：2010-09-07 07:21:36
【问题描述】：
这真的取决于它有多糟糕。
如果它是一个小系统，并且你完全理解它，那么重写并不疯狂。
另一方面，如果它是一个巨大的遗留怪物，拥有一千万行未记录的神秘代码，那么你真的很难完全重写。
需要考虑的要点：
- 如果用户看起来不错，他们 不在乎什么样的意大利面 混乱它是给你的。在另一 手，如果这对他们也不利，那么 更容易达成协议（并且 耐心）。
- 如果你要重写，试着做一个 一次部分。凌乱的， 杂乱无章的代码库可能会使这 困难（即，只更换一个 部分需要重写大 依赖代码的冰山），但如果 可能，这使它变得容易得多 逐步进行重写并得到 用户在此过程中的反馈。
如果不能一次发布一个部分的新版本，我真的会犹豫为大型系统承担一个巨大的重写项目。
【讨论】：
每次使用代码时只需稍微清理一下代码。如果还没有，请设置一个单元测试框架。所有新代码都应该编写测试。任何因错误而修复的旧代码，也请尝试滑入测试。
随着清理工作的进行，您将能够将越来越多的讨厌代码清扫到封装的垃圾箱中。以后就可以一一挑选了。
像 javadoc 或 doxygen 这样的工具，如果尚未使用，也可以帮助改进代码文档和可理解性。
反对完全重写的论据相当强烈。在原始项目的时间范围内编码的大量“小错误”和行为将再次潜入。
【讨论】：
请参阅 Joel Spolsky 的文章 Things You Should Never Do。总而言之，当你重写时，你失去了让当前代码按照它需要的方式工作所学到的所有经验。
【讨论】：
重写任何复杂的东西很少能成功。这很诱人，但百分比很低。
在单元测试中获取遗留代码并对其进行重构，和/或在适当的时候逐步完全替换其中的一小部分。
【讨论】：
重构，除非它确实很糟糕。
Joel has a lot to say on this...
至少，用你面前的旧代码重写代码，不要从头开始。旧代码可能很糟糕，但它是有原因的，如果你忽略它，你最终会看到可能在几年前在旧代码中修复的相同错误。
【讨论】：
-
刚刚差和非常差的分界线在哪里？
在我以前的工作中重写的一个原因是无法找到具有足够经验的开发人员来处理原始代码库。
决定首先清理底层数据库结构，然后进行重写，以便更容易找到全职员工和/或承包商。
我还没有听说结果如何:)
我认为人们倾向于重写，因为表面上看起来更有趣。
我们要从头开始重建！
我们会做对的这次！
等等
【讨论】：
Baley 和 Belcham 的新书 Brownfield Application Development in .NET 即将出版。第一章是免费的，主要从与平台无关的角度讨论这些问题。
【讨论】：
修复，或更重要的是，重构。既是因为Joel said so 也是因为，如果这是您的代码，那么自从您上次接触此代码以来，您可能已经学到了很多东西。如果您是在 .NET 1.1 中编写的，则可以将其升级到 3.5 SP1。您可以进入并清除所有已注释掉的旧代码。作为开发人员，您现在比您第一次编写此代码时好 100 倍。
我认为一个例外是当代码使用真正过时的技术时 - 在这种情况下，编写新版本可能会更好地为您服务。如果您正在查看一些具有 10,000 行代码的 VB6 应用程序，其 Access 数据库后端显然是由不太了解数据库如何工作的人设置的（很可能是八年前的您），那么您可能会拉只需一小部分时间和代码，即可获得更快、基于 C#/SQL 的解决方案。
【讨论】：
这不是那么非黑即白……这真的取决于很多因素（更重要的是“付钱的人想让你做什么”）
在我工作的地方，我们重新编写了一个开发框架，另一方面，我们不断修改一些无法迁移的旧系统（由于客户的技术和时间限制）。在这种情况下，我们尝试保持编码风格，但有时您必须实施很多变通方法，因为它的构建方式
【讨论】：
根据您的情况，您可能有另一种选择：许可内第三方代码。
我曾咨询过几家公司，他们认为这是明智的选择，尽管看似“放弃 IP”可能是管理层的一大障碍。在我现在的公司，我们认真考虑了使用第三方代码替换我们的核心框架的可行选择，但这个想法最终被拒绝更多是出于商业原因而不是技术原因。
为了直接回答您的问题，我们最终选择了重写遗留框架——这个决定我们并没有掉以轻心！ 14 个月过去了，我们一点也不后悔这个选择。仅考虑修复错误所花费的时间，我们的新框架几乎已经收回了成本。不利的一面是，它的功能还不是很完整，所以在我们可以移植最后一个“前端”应用程序之前，我们处于并行维护两个独立框架的令人羡慕的位置。
【讨论】：
我强烈推荐阅读 Michael Feathers 的“有效地使用遗留代码”。这是关于如何重构代码以使其可进行单元测试的指导建议。
【讨论】：