【问题标题】:Legacy code, legacy tools - what to do?遗留代码、遗留工具——怎么办?
【发布时间】:2010-11-18 04:01:27
【问题描述】:

我有一个有点老的项目,我称之为遗产。

它的一些特点是:

  1. 这是一个工作产品(大约 3 年),并且正在持续开发中。
  2. 代码库非常大,包括(CS、SQL、ASPX、Jayrock、JS/HTML/CSS 等)
  3. 平台为 .NET 1.1。
  4. IDE 是 Borland C# Builder 2006(什么...)。
  5. 其他工具是 Enterprise Core Objects 3(适用于 .NET 1.1)(模型驱动架构 - UML 的 O/R-M)。
  6. 另外使用 Telerik RadControls。
  7. 主要是一位活跃的开发人员。
  8. 对业务对象进行了大量测试,但 UI (WebForms) 根本不是可测试的 ATM(未应用 MVP/MVC 等)。
  9. 我不得不接受代码质量不是“最好的”并且仍然保持在“足够好”的标记上(所以这不是 rewrite all from scratch 的主要原因)

这个项目的问题是:

  1. .NET 1.1 - 平台不再“活跃”。
  2. IDE - 一直在苦苦挣扎。只是工作痛苦。糟糕的工具支持,任何重构基本上都是手工完成的。
  3. ECO3 框架 - 为迁移到 ECO5(以及 .NET 3.5)付出了很多努力。
  4. 从 ECO3 迁移到 NHibernate(最好)将花费更多时间(因为所有逻辑/测试都应该重写)。
  5. ECO3 严重依赖 IDE,因此仅更改 IDE 几乎是不可能的。
  6. 通常迁移到 .NET 3.5 需要很长时间(尤其是对于仅 1 个开发人员)。

我想听听有关如何处理此项目的任何建议/提示。
我应该继续在那种环境中工作吗?
如果不是,那么在几天内迁移整个项目的最佳方法是什么(几周内的延迟太长 ATM)。是的,我知道它会在以后得到回报,但我现在不能这样做。

一般欢迎任何建议。

干杯,
德米特里。

【问题讨论】:

    标签: .net asp.net legacy


    【解决方案1】:

    好吧,鉴于您的可用时间跨度,我建议您保留代码并使用它。但无论您要更改或制作新代码,请确保以最佳方式编写代码。

    通常,当您这样做时,随着时间的推移,项目会变得更好,因为有时您可能会更改一些“脏”的部分,嘿,那是您代码中不那么“脏”的部分:)。从长远来看,你应该有一个更干净、更好的编写代码。

    关于 IDE 的变化,我倾向于同意 Martin 的观点。迁移到另一个应该不难。但我建议在你提到的第一个小时间跨度之后再做(除非你是一个冒险的人)。

    【讨论】:

    • 是的。这就是我现在想要做的。但是在那种环境中工作会变得非常令人沮丧:(
    【解决方案2】:

    如果代码只有三年的历史,它还不是遗留的。每三年(甚至每五年)以不同的方式重做事情是 IMO 的浪费。

    OTOH,应该可以毫不费力地用其他 IDE 替换 IDE。

    【讨论】:

    • 没有。 ATM 我无法替换 IDE,因为该工具 (ECO3) 与 IDE 高度集成,无法在它之外工作。更改 IDE 我也必须更改工具。
    【解决方案3】:

    我会分小步进行缓慢的迁移和重构。我的建议依次是:

    • 迁移到“更好”的 IDE(您喜欢的,可能是 Visual Studio?)
    • 迁移到使用 .NET 3.5 功能。根据需要进行重构以利用泛型和 LINQ 等新功能
    • 根据需要开始更新您的业务逻辑

    除了更改 IDE 之外,其他所有事情都可以通过标准重构实践在代码库的一小部分上以非常小的步骤完成。不需要全部重写。

    【讨论】:

    • 更改 IDE 需要将 ECO3 更改为 ECO5。但是,是的,ATM IDE 是最大的问题,我确实喜欢 VS。
    • 库不应影响您的 IDE——至少不会直接影响。您可能会失去自动生成代码的能力,但生成的代码模型应该可以移植并在任何 IDE 中编译。我仍然会专注于我上面所说的。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2011-06-11
    • 2017-05-20
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2010-09-09
    • 2012-05-16
    相关资源
    最近更新 更多