重构经典ASP的最佳实践?

假设

经典ASP系统的文档相当简单。

因为您一直在使用RubyonRails,所以您的(VB/C#)ASP.NET充其量也可以。

我也继承了一个经典的ASP系统,它是由EXCELVBA类型随意拼凑而成的。有很多这样的东西 <font size=3>crap</font>

我使用了jEdit和CTAG(如 jamting 上面),以及其他一些插件。

我的建议 尝试创建一个主包含文件,从中导入所有常用的内容。诸如登录/注销、数据库访问、web服务、javascript库等。

正确缩进脚本。

议论

编写外部架构文档。我个人使用LyX,因为生成格式良好的pdf格式会让人头疼,但你可以随意使用。如果使用wiki,请安装graphviz加载项并使用它。制作可以轻松修改的快速图表非常容易。

因为我不知道这些增强需要有多大的实质性,所以我建议在规划这些增强时,有一个好的从高级到中级的体系结构文档是非常有用的。

在业务逻辑单元测试中,我发现唯一有效的方法是在asp中设置一个xml rpc侦听器,该侦听器导入主库,并在主库的任何子包含中公开函数(而不是子例程),然后分别构建,使用一种语言的单元测试系统,该语言更好地支持通过xml rpc调用ASP函数的功能。我使用python,但我认为Ruby应该做到这一点。(这有意义吗?)。很酷的一点是,编写软件单元测试部分的人甚至不需要看ASP代码,只要他们对要调用的函数有适当的描述,这样他们就可以成为你身边的人。

有一个项目叫做 aspunit 在sourceforge,但上一次发布是在2004年,它被标记为非活动。从未使用过它,但它是纯vbscript。粗略地看一下代码,就知道作者知道他们在做什么。

最后,如果你需要帮助,我可以做合同规定的远程办公工作(每周最多8小时)。请按照链接线索查找联系人信息。

祝你好运嗯。

由于完全重写一个工作系统可能非常危险,我只能给你一个小提示:在你的项目上设置丰富的标记,CTAG。通过这种方式,您可以跳转到函数和子函数的定义,我认为这很有帮助。

论逻辑与“观点”的分离。VBScript支持类的som类OO。我倾向于编写符合我在asp页面上作为“视图”包含的逻辑的类。然后我将视图与Username:<%=MyAccount.UserName%>。MyAccount类还可以有一些方法,如:MyAccount.Login()等。

有点原始,但至少您可以封装一些代码并将其隐藏在HTML中。

请参阅这篇文章,了解从老式asp向asp.NET过渡的详细信息

Refactoring ASP

关于未来的发展方向,我的目标不是ASP.NET web表单,而是微软新的MVC框架(ASP.NET的一个附加组件),从经典的ASP.NET迁移到这个框架会简单得多。

ASPUnit 对于我们的一些经典ASP进行单元测试,并发现它很有帮助。它可能很旧,但ASP也是。它很简单,但确实有效,如果需要,您可以自定义或扩展它。

我还发现 Working Effectively with Legacy Code 作者MichaelFeathers希望能成为一个有用的指南,帮助您找到方法来测试一些旧代码。

包含文件可以帮助您保持简单。有一次,我尝试为每个类创建一个include,但效果不太好。我喜欢有两个包含普通业务逻辑的主include,对于复杂的页面,有时每个页面都有一个包含逻辑的include。我想您可以使用类似的设置来实现MVC。

如果代码是由不同的人编写/维护的,则可能存在编码风格不一致的问题。我发现,将代码放回行中可以更容易地看到可以重构的东西。

“数千行”让我怀疑,在某些情况下,松散相关的内容可能会显示在同一页面上。同样,您希望将它们抽象为单独的子例程。

这已经很旧了,但我忍不住加了两分钱。如果必须重写,并且必须继续使用经典ASP:

• 使用JScript!更强大的是,您可以获得继承,还有一些好的好处,比如使用与客户端相同的方法进行服务器端验证
• 你完全可以做MVC——我写了一个MVC框架,没有那么多代码行
• 确保您正在执行参数化查询,并且始终返回断开连接的记录集

软件开发项目管理实践表明,像这样的软件需要退役。

但仍然如此。有必要开始开发新的软件。这是根本不可能永远保持这一点,他们等待退休的日志更糟。

如果您没有合适的规范/需求文档(我认为世界上没有asp软件,考虑到这些编码人员的无障碍能力),您将需要一组了解软件功能的用户和一个负责验证需求的经理。您需要检查每个功能并记录其需求。

在此过程中,您将进一步了解该软件及其业务。一旦你有足够的信息,你可以开始开发一个新的。