代码之家 › 专栏 › 技术社区 › neouser99

如果我们的系统需要大修,最好的方法是什么?

vbscript asp-classic python

neouser99 · 技术社区 · 18 年前

我们正在维护一个基于经典ASP的Web应用程序,它使用vbscript作为主要语言。我们同意我们的后端系统(如果您愿意的话,框架)已经过时,不能为我们提供快速前进的适当工具。我们几乎已经完全接受了当前的WebMVC模式,并且不能以合理的方式使用当前的技术。缺少的主要功能是适当的分派和模板化,以及继承。

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

使用JScript将现有的应用程序移植到经典的ASP,这样我们就可以轻松地从那里移植到.NET MSJScript,并最终在.NET平台上完成工作(我们认为,MVC的工作最好在那时完成,ASP.NET并没有比现在更好)。这被认为是一条比下一个选择更安全、风险更小的道路,尽管可能需要更长的时间。
使用其他一些技术完全重写应用程序,现在包的领导者是具有定制框架、ORM和良好模板化解决方案的python wsgi。这里有回旋的空间,即使是Django和其他预建的解决方案。这种方法可能是最快的解决方案,因为我们可能会在实际产品旁边运行一个测试版,但是如果我们不能/不正确地得到它,它确实有可能浪费大量时间。

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

现在,这个问题。有人走上面两条路中的任何一条吗?如果是这样的话,它成功了吗,它怎么可能更好呢,等等。我们并不打算偏离这两件事中的一件,但是一些建议或其他解决方案可能会有帮助。

9 回复 | 直到 18 年前

Michael Pryor 18 年前

不要丢弃你的代码!

这是你能犯的最严重的一个错误(在大型代码库上)。见 Things You Should Never Do, Part 1 .

你已经在旧代码上投入了大量的精力,并解决了许多错误。扔掉它是开发人员的一个典型错误(也是我做过很多次的错误)。它让你感觉“更好”,就像弹簧清洁。但你不需要买一套新公寓和所有新家具来装饰你的房子。你可以一次在一个房间里工作…也许有些东西只是需要一个新的油漆工。因此,这就是重构的切入点。

对于应用程序中的新功能, write it in C# and call it from your classic ASP . 当您重写这个新代码时,您将被迫被模块化。当您有时间的时候,也可以将旧代码的一部分重构为C,并在执行过程中解决错误。最终,您将用所有新代码替换您的应用程序。

您也可以编写自己的编译器。很久以前,我们为经典的ASP应用程序编写了一个脚本,允许我们输出PHP。它叫 Wasabi 我认为这就是杰夫·阿特伍德认为乔尔·斯波斯基发疯的原因。实际上,也许我们应该把它装船,然后你就可以用它了。

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

此外,如果这是一个内部唯一的应用程序,只需离开它。不要重写它-您是唯一的客户,如果您需要将其作为经典的ASP运行,您可以满足这个要求。

easeout 18 年前

利用此机会删除未使用的功能!一定要用新语言。叫它2。重建你真正需要的80%的重建工作会少得多。

首先把你的大脑擦干净整个应用程序。坐下来列出它的总体目标,然后根据使用的特性来决定需要哪些特性。然后根据这些特性重新设计它,并构建。

(我喜欢删除代码。)

S.Lott 18 年前

结果比你想象的要好。

最近我做了一个大型的逆向工程工作,处理了一个可怕的C代码旧集合。我按函数重新分配仍然与类相关的特性,为类编写单元测试,并构建看起来像是替换应用程序的功能。它有一些通过类的原始“逻辑流”,一些类的设计很差[主要是因为全局变量的子集太难区分]。

它通过了类级和整个应用程序级的单元测试。传统的源代码主要被用作一种“C中的规范”,以找出真正晦涩的业务规则。

去年,我写了一个替换30岁的COBOL的项目计划。客户倾向于Java。作为计划工作的一部分,我使用Django在python中构建了修改后的数据模型的原型。我可以在完成计划之前演示核心事务。

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

由于“我们需要使用Java”的心态,由此产生的项目将比完成Django演示更大和更昂贵。没有实际价值来平衡成本。

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

注释 :我有一个正在工作的Django实现(仅限模型和管理页面),用于计划其余工作。

在Django中进行这种原型设计的最好的部分是,在得到模型、单元测试和管理页面之前,您可以把它们搞得一团糟。 正确的 .一旦模型正确,你就可以把剩下的时间花在用户界面上,直到所有人都满意为止。

Hallgrim 18 年前

不管你做什么,看看你是否能按照一个计划去做,在这个计划中你不必一下子就把所有的应用程序都移植到一个大爆炸中。把所有的错误都抛到一边,从头开始是很有诱惑力的,但是如果你能逐渐做到这一点,你所犯的错误就不会花那么多钱,也不会引起如此多的恐慌。

pi. 18 年前

半年前,我接手了一个大型Web应用程序(幸运的是已经在Python中),它存在一些主要的体系结构缺陷(模板和代码混合、代码重复、您命名它…)。

我的计划是最终让系统对WSGi做出响应,但我还没有到那里。我发现最好的办法是小步走。在过去的6个月里,代码重用得到了提高,而且进展也加快了。

适用于我的一般原则:

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

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

Forgotten Semicolon adrianm 18 年前

我不推荐JScript,因为这绝对是一条走得比较少的路。 ASP.NET MVC正在迅速成熟,我认为您可以开始向它迁移,同时随着ASP.NET MVC框架的最终确定的完成,它也会逐渐升级。另一种选择是使用ASP.NET w/亚音速或NHibernate。

myid 18 年前

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

Jason Baker 17 年前

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

pbreitenbach 17 年前

我同意MichaelPryor和Joel的观点,继续开发现有的代码库,而不是从头开始重新编写,这几乎总是一个更好的主意。为了提高性能或灵活性,通常有机会重新编写或重新考虑某些组件。