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

目前正在讨论两条路径:

  1. 使用 JScript 将现有应用程序移植到经典 ASP,这将使我们能够顺利地从那里转到 .NET MSJscript,并最终到达 .NET 平台(最好是 MVC 的东西到那时就可以完成,ASP。在我们看来,. NET 并不比我们现在的情况好多少)。这被认为是比下一个选择更安全、风险更小的路径,尽管可能需要稍长的时间。
  2. 使用其他一些技术完全重写应用程序,目前该包的领导者是带有自定义框架、ORM 和良好模板解决方案的 Python WSGI。即使 django 和其他预构建的解决方案也有回旋余地。这种方法有望成为最快的解决方案,因为我们可能会在实际产品旁边运行测试版,但如果我们不能/不正确,它确实有可能浪费大量时间。

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

现在,问题来了。有人走过上述两条路吗?如果是这样,它是否成功,如何做得更好等等。我们不希望与这两件事中的其中一件有太大偏差,但一些建议或其他解决方案可能会有所帮助。

有帮助吗?

解决方案

不要扔掉你的代码!

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

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

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

您也可以编写自己的编译器。很久以前,我们为我们的经典 ASP 应用程序编写了一个,以允许我们输出 PHP。它被称为 芥末 我认为这就是杰夫·阿特伍德认为乔尔·斯波尔斯基发疯的原因。事实上,也许我们应该直接发货,然后你就可以使用它了。

它允许我们在下一个版本中将整个代码库切换到 .NET,同时只重写源代码的一小部分。这也导致一堆人骂我们疯了,但是编写一个编译器并没有那么复杂,而且给了我们很大的灵活性。

另外,如果这是仅供内部使用的应用程序,请保留它。不要重写它 - 您是唯一的客户,如果您需要将其作为经典 asp 运行,您可以满足该要求。

其他提示

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

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

(我喜欢删除代码。)

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

最近,我对一组丑陋的旧 C 代码进行了一项大型逆向工程工作。我按功能重新分配了仍然与类相关的功能,为类编写了单元测试,并构建了看起来像替换应用程序的内容。它有一些通过类的原始“逻辑流”,并且一些类设计得很糟糕[这主要是因为全局变量的子集太难区分。]

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

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

笔记: :在 Django 中构建模型和管理界面比规划整个项目更快。

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

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

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

在 Django 中进行此类原型设计的最佳部分是,您可以随意修改模型、单元测试和管理页面,直到您掌握它为止 正确的. 。一旦模型正确,您就可以将剩下的时间花在摆弄用户界面上,直到每个人都满意为止。

无论您做什么,看看您是否能够设法遵循一个计划,而不必一次性移植所有应用程序。人们很容易把一切都扔掉,从头开始,但如果你能逐步做到这一点,那么你所犯的错误就不会付出太大的代价,也不会引起那么多的恐慌。

半年前,我接手了一个大型 Web 应用程序(幸运的是已经使用了 Python),该应用程序存在一些主要的架构缺陷(模板和代码混合、代码重复,凡是你能想到的......)。

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

对我有用的一般原则:

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

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

我不会推荐 JScript,因为这绝对是一条少有人走的路。ASP.NET MVC 正在迅速成熟,我认为您可以开始迁移到它,同时在 ASP.NET MVC 框架完成后逐步升级。另一种选择是使用 ASP.NET w/Subsonic 或 NHibernate。

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

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

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

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top