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

时间:2020-03-05 19:00:01  来源:igfitidea点击:

我们正在维护一个使用VBScript作为主要语言,基于Classic ASP构建的Web应用程序。我们同意我们的后端(如果需要的话)是过时的,并且没有为我们提供适当的工具来快速前进。我们几乎已经接受了目前遍布各地的当前webMVC模式,并且不能以合理的方式使用当前技术来实现。缺少的主要功能是正确的调度和继承模板。

当前正在讨论两条路径:

  • 使用JScript将现有应用程序移植到Classic ASP,这将使我们希望从那里迁移到.NET MSJscript不会有太多麻烦,最终可以在.NET平台上使用(最好在那时由ASP完成MVC的工作)。 NET并没有比我们目前认为的要好得多。有人认为这是比下一个方案更安全,风险更低的方案,尽管可能会花费更长的时间。
  • 使用其他一些技术完全重写应用程序,现在,该包的领导者是具有定制框架,ORM和良好模板解决方案的Python WSGI。这里甚至还有django和其他预建解决方案的摆动空间。该方法有望成为最快的解决方案,因为我们可能会在实际产品旁边运行beta,但如果我们不能正确地做到这一点,它确实有可能浪费大量时间。

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

现在,这个问题。有没有人选择以上两种方式中的任何一种?如果是这样,那么它是否成功,它会如何更好?

解决方案

回答

借此机会删除未使用的功能!绝对要使用新语言。称之为2.0。重建我们真正需要的80%的工作会少很多。

从擦拭整个应用程序的大脑开始。坐下来列出其总体目标,然后根据使用的功能来决定需要哪些功能。然后考虑这些功能重新设计并构建。

(我喜欢删除代码。)

回答

我不建议使用JScript,因为这绝对是少走的路。
ASP.NET MVC迅速成熟,我认为我们可以开始对其进行迁移,同时随着ASP.NET MVC框架的定稿完成而逐步增加。
另一个选择是使用类似Subsonic或者NHibernate的ASP.NET。

回答

无论我们做什么,都可以查看是否可以按照计划进行操作,而不必大费周章地移植应用程序。试图将其全部丢弃并从头开始是很诱人的,但是如果我们能够逐步做到这一点,那么我们所犯的错误将不会花费那么多,也不会引起太多的恐慌。

回答

它的效果比我们想象的要好。

最近,我对一个糟糕的旧C代码集进行了大型的逆向工程。我逐个功能地重新分配了仍与类相关的功能,为这些类编写了单元测试,并构建了看起来像替换应用程序的功能。它在类中具有一些原始的"逻辑流",并且某些类的设计不良(主要是因为全局变量的子集太难理解了。)

它在类级别和整个应用程序级别通过了单元测试。遗留资源通常被用作一种" C规范",以找出真正晦涩难懂的业务规则。

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

注意:在Django中建立模型和管理界面比计划整个项目更快。

由于"我们需要使用Java"的思想,因此完成的项目将比完成Django演示更大,更昂贵。没有实际价值来平衡该成本。

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

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

在Django中进行这种原型制作的最好的部分是,我们可以弄乱模型,单元测试和管理页面,直到正确为止。一旦模型正确,我们就可以将剩余的时间花在用户界面上,直到每个人都满意为止。

回答

不要扔掉代码!

这是我们可能会犯的最严重的错误(在大型代码库上)。查看我们不应该做的事情,第1部分。

我们已经为旧代码投入了大量精力,并解决了许多错误。扔掉它是一个经典的开发人员错误(而且我已经做过很多次了)。就像春季大扫除一样,它使我们感觉"更好"。但是,我们无需购买新公寓和所有新家具即可为房屋装潢。我们可以一次在一个房间上工作...也许有些事情只需要一个新的绘画作业。因此,这就是重构的用武之地。

对于应用程序中的新功能,请在经典的ASP中使用Cand编写它。重写此新代码时,我们将被迫模块化。如果有时间,可以将部分旧代码很好地重构到Cas中,然后逐步解决这些错误。最终,我们将用所有新代码替换应用程序。

我们也可以编写自己的编译器。很久以前,我们为经典的ASP应用程序编写了一个,以便我们输出PHP。这就是Wasabi,我认为这就是Jeff Atwood认为Joel Spolsky走出摇滚乐的原因。实际上,也许我们应该将其发货,然后我们就可以使用它了。

它允许我们在下一版本中将整个代码库切换到.NET,而仅重写源代码的一小部分。这也使很多人称呼我们为疯,但是编写编译器并不那么复杂,它为我们提供了很大的灵活性。

另外,如果这是内部唯一的应用程序,则将其保留。不要重写它,因为它是唯一的客户,并且如果我们需要以经典asp的身份运行它,则可以满足该要求。

回答

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

回答

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

我的计划是最终让系统响应WSGI,但我还没有。我发现最好的方法就是一步一步。在过去的6个月中,代码重用得到了提高,并且进度加快了。

对我有用的一般原则:

  • 丢弃未使用或者未注释掉的代码
  • 丢弃所有无用的评论
  • 定义应用程序的层层次结构(模型,业务逻辑,视图/控制器逻辑,显示逻辑等)。这不必是非常明确的体系结构,而应考虑应用程序的各个部分,并更好地对代码进行分类。
  • 如果某些内容严重违反了此层次结构,请更改有问题的代码。移动代码,在其他地方重新编码,等等。与此同时,调整应用程序的其余部分以使用此代码,而不是旧代码。如果不再使用,则将旧的扔掉。
  • 让API变得简单!

进度可能会非常缓慢,但是值得。

回答

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

回答

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