我敢肯定，我们到过那里，都在一个项目中，那里有一个破旧的旧代码库，几乎不能满足目的，我们必须决定从头开始重写它或者修复已经存在的代码。

传统观点倾向于建议我们不要尝试从头开始重写，因为失败的风险非常高。那么，面对这个问题，我们做了什么？我们是如何做出决定的？结果如何？

解决方案

回答

它不是那么黑白...实际上取决于很多因素(更重要的是"付钱给人想要我们做什么")

在我工作的地方，我们重新编写了开发框架，另一方面，我们不断修改一些无法迁移的旧系统(由于客户端的技术和时间限制)。在这种情况下，我们尝试保留编码风格，有时由于其构建方式，我们必须实现许多变通方法

回答

除非确实非常糟糕，否则请重构。

乔尔对此有很多话要说...

至少，用我们面前的旧代码重写代码，而不仅仅是从头开始。旧代码可能很糟糕，但这是有原因的，如果我们忽略它，最终将看到与几年前旧代码中已修复的错误相同的错误。

回答

请参阅Joel Spolsky的文章"我们不应该做的事情"。总而言之，当我们进行重写时，我们将失去为使当前代码按其需要的方式工作而学到的所有课程。

另请参阅：泥浆大球

回答

每次使用它时，只需对其进行一点整理即可。如果还没有，请设置一个单元测试框架。所有新代码都应编写测试。由于错误而修复的所有旧代码，也请尝试插入测试。

随着清理的进行，我们将能够将越来越多的讨厌代码扫入封装的垃圾箱中。然后，我们将来可以一一挑选。

诸如javadoc或者doxygen之类的工具(如果尚未使用)也可以帮助改善代码文档和可理解性。

反对完整的论点重写得很强烈。在原始项目的时间范围内编码的大量"小错误"和行为将再次潜入。

回答

在我之前的工作之一上进行重写的原因之一是无法找到具有足够经验的开发人员来处理原始代码库。

决定首先清理基础数据库结构，然后重写某些内容，以便更轻松地找到全职员工和/或者承包商。

我还没有听说它是如何工作的:)

我认为人们倾向于重写，因为表面上看起来更有趣。

我们从头开始重建！

这次我们会做的正确！

等等。

回答

很难成功重写任何复杂的东西。这很诱人，但却是低比例的策略。

在单元测试下获取遗留代码并对其进行重构，和/或者在适当时逐步增量地完全替换其中的一小部分。

回答

这实际上取决于它的严重程度。

如果它是一个小型系统，并且我们完全理解它，那么重写并不疯狂。

另一方面，如果它是一个巨大的遗留怪物，具有一千万行未记录的神秘代码，那么我们将很难完全重写。

要考虑的要点：

• 如果对用户来说看起来不错，他们将不会在意它给我们带来什么样的意大利面条。另一方面，如果这也对他们不利，那么更容易达成协议(和耐心)。
• 如果确实要重写，请尝试一次做一次。杂乱无章的代码库可能会使其困难(例如，仅替换一部分就需要重写大量的依赖代码冰山)，但是，如果可能的话，这使得逐步进行重写并从用户那里获得反馈变得容易得多。

我真的很犹豫是否要承担大型系统的大型改写项目，而又不能一次发行一个新版本。

回答

即将出版一本新书，作者是Baley和Belcham撰写的.NET中的Brownfield应用程序开发。第一章是免费的，主要从平台不可知的角度讨论这些问题。

回答

根据情况，我们可能还有另一种选择：许可内第三方代码。

我曾在几家公司咨询过，尽管似乎"扔掉IP"可能是管理的一大障碍，但这是明智的选择。在我目前的公司中，我们认真考虑了使用第三方代码代替我们的核心框架的可行选择，但最终该想法最终被拒绝的原因是业务原因而不是技术原因。

为了直接回答问题，我们最终选择重写遗留框架，这是我们轻描淡写的决定！ 14个月后，我们完全不后悔这个选择。仅考虑花费在修复错误上的时间，我们的新框架几乎已经收回了成本。不利的一面是，它还不是很完整的功能，因此，我们无法并行维护两个单独的框架，直到可以移植最后一个"前端"应用程序为止。

回答

我强烈建议阅读Michael Feathers撰写的"有效使用旧版代码"。它是有关如何重构代码以使其可进行单元测试的教练建议。

回答

进行维修，或者更重要的是，进行重构。这既是因为Joel这么说，也是因为，如果这是代码，自从我们上次触摸此代码以来，我们可能已经学到了很多东西。如果是在.NET 1.1中编写的，则可以将其升级到3.5 SP1. 我们可以进入并清除所有旧的注释掉的代码。与我们最初编写此代码时相比，我们现在作为开发人员要好100倍。

我认为一个例外是，当代码使用真正过时的技术时，在这种情况下，编写新版本可能会更好。如果我们正在查看带有10,000行代码且带有Access数据库后端的某些VB6应用程序，而该数据库显然是由对数据库的工作方式不了解的人(很可能是八年前)设置的，则可以在短短的时间和代码中实现了基于C＃/ SQL的更快解决方案。