3

我们正在维护一个使用 VBScript 作为主要语言基于 Classic ASP 构建的 Web 应用程序。我们一致认为我们的后端(如果您愿意的话是框架)已经过时并且没有为我们提供快速前进的适当工具。我们几乎已经接受了无处不在的当前 webMVC 模式,并且无法以合理的方式使用当前的技术来做到这一点。最大的缺失特性是正确的调度和继承模板等。

目前有两条路径正在讨论:

  1. 使用 JScript 将现有应用程序移植到 Classic ASP,这将使我们有希望从那里转到 .NET MSJscript 而没有太多麻烦,并最终在 .NET 平台上结束(最好 MVC 的东西到那时就完成了,ASP.NET)。在我们看来,NET 并没有比现在好多少)。这被认为是比下一个选择更安全、风险更低的路径,尽管它可能需要更长的时间。
  2. 使用其他一些技术完全重写应用程序,现在这个包的领导者是 Python WSGI,它有一个自定义框架、ORM 和一个很好的模板解决方案。这里甚至还有 django 和其他预建解决方案的回旋余地。这种方法有望成为最快的解决方案,因为我们可能会在实际产品旁边运行测试版,但如果我们不能/不正确,它确实有可能浪费大量时间。

这并不意味着我们的逻辑消失了,因为我们多年来建立的东西相当稳定,正如我们所说的那样难以处理。它建立在 SQL Server 2005 之上,大量使用存储过程,并在 IIS 6 上发布,只是为了提供更多背景知识。

现在,问题。有没有人采取上述两条路径中的任何一条?如果是这样,它是否成功,它怎么可能更好,等等。我们不希望在做这两件事中偏离太多,但一些建议或其他解决方案可能会有所帮助。

4

9 回答 9

7

不要扔掉你的代码!

这是您可能犯的最严重的错误(在大型代码库上)。请参阅您不应该做的事情,第 1 部分

您已经在旧代码上投入了大量精力并解决了许多错误。把它扔掉是一个典型的开发人员错误(我已经做过很多次了)。它让你感觉“更好”,就像大扫除一样。但是您不需要购买新公寓和所有新家具来装备您的房子。你可以一次在一个房间里工作……也许有些事情只需要一个新的油漆工作。因此,这就是重构的用武之地。

对于您的应用程序中的新功能,用 C# 编写它并从您的经典 ASP 中调用它。当你重写这个新代码时,你将被迫模块化。当您有时间时,也可以将部分旧代码重构为 C#,并随时解决错误。最终,您将使用所有新代码替换您的应用程序。

您也可以编写自己的编译器。我们很久以前为我们的经典 ASP 应用程序编写了一个,以允许我们输出 PHP。它叫做芥末,我认为这就是杰夫阿特伍德认为乔尔斯波尔斯基失控的原因。实际上,也许我们应该把它寄出去,然后你就可以使用它了。

它允许我们将整个代码库切换到 .NET 以用于下一个版本,同时只重写我们源代码的一小部分。也让很多人骂我们疯了,但是写一个编译器也没那么复杂,给了我们很大的灵活性。

此外,如果这是一个仅限内部的应用程序,请离开它。不要重写它——你是唯一的客户,如果你需要将它作为经典的 asp 运行,你可以满足这个要求。

于 2008-09-18T02:19:51.713 回答
3

以此为契机,删除未使用的功能!一定要使用新语言。称之为 2.0。重建你真正需要的 80% 的工作量会少很多。

首先从整个应用程序中清除您的大脑。坐下来列出其总体目标,然后根据使用的功能决定需要哪些功能。然后根据这些功能重新设计它,然后构建。

(我喜欢删除代码。)

于 2008-09-17T20:53:43.213 回答
3

它的效果比你想象的要好。

最近,我对一个可怕的旧 C 代码集合进行了一项大型逆向工程工作。逐个函数我将仍然相关的特性重新分配到类中,为类编写单元测试,并构建了一个看起来像替换应用程序的东西。它有一些通过类的原始“逻辑流”,并且一些类设计得很糟糕[主要是因为全局变量的一个子集太难以梳理。]

它通过了类级别和整个应用程序级别的单元测试。遗留源代码主要用作一种“C 语言规范”,以找出真正晦涩难懂的业务规则。

去年,我写了一个替换 30 年的 COBOL 的项目计划。客户倾向于 Java。作为规划工作的一部分,我使用 Django 在 Python 中对修改后的数据模型进行了原型设计。在我完成计划之前,我可以演示核心交易。

注意:在 Django 中构建模型和管理界面比将项目规划为一个整体要快。

由于“我们需要使用 Java”的心态,最终的项目将比完成 Django 演示更大更昂贵。没有真正的价值来平衡该成本。

此外,我为需要成为 Web 应用程序的 VB 桌面应用程序做了相同的基本“Django 原型”。我在 Django 中构建了模型,加载了遗留数据,并在几周内启动并运行。我使用该工作原型来指定其余的转换工作。

注意:我有一个可用的 Django 实现(仅限模型和管理页面),我用它来计划其余的工作。

在 Django 中进行这种原型设计的最好的部分是,您可以在模型、单元测试和管理页面中乱七八糟,直到您做为止。一旦模型正确,您就可以将剩下的时间花在摆弄用户界面上,直到每个人都满意为止。

于 2008-09-17T21:44:51.437 回答
2

不管你做什么,看看你是否能设法遵循一个你不必一次性移植应用程序的计划。抛开一切从头开始是很诱人的,但如果你能逐渐做到这一点,你所犯的错误就不会花费太多,也不会引起如此多的恐慌。

于 2008-09-17T21:08:42.273 回答
1

半年前,我接管了一个大型 Web 应用程序(幸运的是已经在 Python 中),它存在一些主要的架构缺陷(模板和代码混合,代码重复,你说的......)。

我的计划是最终让系统响应 WSGI,但我还没有。我发现最好的方法是小步骤。在过去的 6 个月中,代码重用率有所提高,并且进展加快。

对我有用的一般原则:

  1. 丢弃未使用或注释掉的代码
  2. 扔掉所有没用的评论
  3. 定义应用程序的层层次结构(模型、业务逻辑、视图/控制器逻辑、显示逻辑等)。这不必是非常明确的架构,而是应该帮助您考虑应用程序的各个部分并帮助您更好地对代码进行分类。
  4. 如果某些东西严重违反了这个层次结构,请更改有问题的代码。移动代码,在另一个地方重新编码,等等。同时调整应用程序的其余部分以使用此代码而不是旧代码。如果不再使用,请将旧的扔掉。
  5. 让您的 API 保持简单!

进展可能非常缓慢,但应该值得。

于 2008-09-19T10:56:06.033 回答
0

我不会推荐 JScript,因为那绝对是少有人走的路。ASP.NET MVC 正在迅速成熟,我认为您可以开始迁移到它,同时随着 ASP.NET MVC 框架的完成而加速。另一种选择是使用类似 ASP.NET w/Subsonic 或 NHibernate 的东西。

于 2008-09-17T20:55:23.100 回答
0

不要尝试使用 2.0(比当前存在或计划的更多功能),而是构建您的新平台,以解决代码库的当前问题(可维护性/速度/wtf)并从那里开始。

于 2008-09-18T02:23:49.673 回答
0

如果您正在考虑迁移到 Python,一个好的开始是在 Django 中重写您的管理员界面。这将帮助您解决一些问题,使 Python 启动并与 IIS 一起运行(或将其迁移到 Apache)。说到这,我推荐isapi-wsgi。到目前为止,这是启动和运行 IIS 的最简单方法。

于 2009-02-27T00:10:31.847 回答
0

我同意 Michael Pryor 和 Joel 的观点,即继续发展现有的代码库而不是从头开始重写几乎总是一个更好的主意。通常有机会重写或重构某些组件以提高性能或灵活性。

于 2009-06-15T02:33:35.893 回答