13

我敢肯定你们都去过那里,你们承担了一个项目,其中有一个老旧的代码库,几乎不适合目的,你必须决定要么从头开始重新编写它,要么修复已经存在的代码。

传统观点倾向于建议您永远不要尝试从头开始重写,因为失败的风险非常高。那么当你遇到这个问题时你做了什么,你是如何做出决定的,结果如何?

4

11 回答 11

10

每次使用它时,只需稍微清理一下代码。如果还没有,请设置一个单元测试框架。所有新代码都应该编写测试。由于错误而修复的任何旧代码,也请尝试滑入测试。

随着清理工作的进行,您将能够将越来越多的讨厌代码扫入封装的垃圾箱中。以后就可以一一挑选了。

像 javadoc 或 doxygen 这样的工具,如果尚未使用,也可以帮助改进代码文档和可理解性。

反对完全重写的论据相当强烈。在原始项目的时间范围内编码的大量“小错误”和行为将再次潜入。

于 2008-08-29T20:32:40.943 回答
10

这真的取决于它有多糟糕。

如果它是一个小系统,并且您完全理解它,那么重写并不疯狂。

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

需要考虑的要点:

  • 如果它对用户来说看起来不错,他们不会在乎它对你来说是什么样的意大利面。另一方面,如果这对他们也不利,那么就更容易达成一致(和耐心)。
  • 如果您确实要重写,请尝试一次完成一部分。杂乱无章的代码库可能会使这变得困难(即,仅替换一个部分需要重写大量依赖代码的冰山),但如果可能的话,这使得逐步进行重写并在此过程中从用户那里获得反馈变得容易得多.

如果不能一次发布一个新版本,我真的会犹豫为一个大型系统承担一个巨大的重写项目。

于 2008-08-29T20:39:23.800 回答
5

请参阅 Joel Spolsky 的文章《你不应该做的事》。总而言之,当你重写时,你失去了让当前代码按照它需要的方式工作的所有经验教训。

参见:大泥球

于 2008-08-29T20:31:47.343 回答
3

重写任何复杂的东西很少能成功。这很诱人,但策略百分比很低。

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

于 2008-08-29T20:35:18.677 回答
2

重构,除非它确实非常糟糕。

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

至少,用你面前的旧代码重写代码,不要从头开始。旧代码可能很糟糕,但这就是它的原因,如果你忽略它,你最终会看到可能在几年前在旧代码中修复的相同错误。

于 2008-08-29T20:31:35.517 回答
2

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

决定首先清理底层数据库结构,然后重写一些可以更容易找到全职员工和/或承包商的东西。

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

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

我们要从头开始重建!

这次我们会做对的!

等等

于 2008-08-29T20:34:42.483 回答
2

Baley 和 Belcham出版了一本新书《.NET 中的棕地应用程序开发》 。第一章是免费的,主要从与平台无关的角度讨论这些问题。

于 2008-08-29T20:46:40.567 回答
2

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

我认为的一个例外是当代码使用真正过时的技术时——在这种情况下,编写新版本可能会更好地为您服务。如果您正在查看一些具有 10,000 行代码的 VB6 应用程序,其 Access 数据库后端显然是由不太了解数据库如何工作的人设置的(很可能是八年前的您),那么您可能会拉只需一小部分时间和代码即可获得更快的、基于 C#/SQL 的解决方案。

于 2008-09-30T03:38:49.517 回答
1

它不是那么非黑即白......它真的取决于很多因素(更重要的是“付钱的人想让你做什么”)

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

于 2008-08-29T20:29:50.263 回答
1

根据您的情况,您可能还有另一种选择:许可内第三方代码。

我曾咨询过几家公司,认为这将是明智的选择,尽管看似“丢弃 IP”可能是管理的一大障碍。在我现在的公司,我们认真考虑了使用第三方代码来替换我们的核心框架的可行选择,但这个想法最终被拒绝更多是出于商业原因而不是技术原因。

为了直接回答您的问题,我们最终选择了重写遗留框架——我们没有掉以轻心的决定!14 个月过去了,我们一点也不后悔这个选择。仅考虑修复错误所花费的时间,我们的新框架几乎已经收回成本。不利的一面是,它的功能还不是很完整,所以在我们可以移植最后一个“前端”应用程序之前,我们处于并行维护两个独立框架的令人羡慕的位置。

于 2008-08-29T22:47:07.050 回答
1

我强烈推荐阅读 Michael Feathers 的“Working Effectively with Legacy Code”。它是关于如何重构代码以使其可进行单元测试的指导建议。

于 2008-09-30T03:09:05.797 回答