重构经典 ASP 的最佳实践?
-
09-06-2019 - |
题
我必须在一个大型、旧的、充满意大利面条的 ASP 系统中进行一些重大开发。我已经离开 ASP 很长一段时间了,把精力集中在 Rails 开发上。
我采取的一个基本步骤是将页面重构为具有有意义名称的子项和函数,这样至少可以很容易地理解@文件顶部通常发生的情况。
有没有值得用的ASP MVC 框架?或者如何至少从视图中获取业务逻辑的最佳实践?(我记得当时做了很多包含 - 这仍然是这样做的方法吗?)
我也很想对业务逻辑进行一些单元测试,但也许我要求太多了?
更新:
该项目中有超过 200 个 ASP 脚本,大约有数千行长;)呃!
我们可能会选择“大重写”,但在那之前,当我更改页面时,我想花一些额外的时间来清理意大利面条。
解决方案
假设
Classic ASP 系统的文档相当简单。
管理层并不寻求重写。
由于您一直在 Rails 上使用 Ruby,因此您的 (VB/C#) ASP.NET 充其量只是还过得去。
我的经验
我也继承了一个经典的 ASP 系统,该系统是由前 excel-vba 类型随意拼凑在一起的。有很多这样的东西 <font size=3>crap</font>
(有时会缺少结束标签;啊啊啊!)。在 2.5 年的时间里,我添加了一个安全系统、一个通用库、CSS+XHTML,并能够强制验证 xhtml1.1(不幸的是,没有正确的 mime 类型),并构建了一个相当强大的 ajaxy 报告系统每天有 80 位用户使用。
我使用了 jEdit 和 cTags(如 堵塞 上面),以及一堆其他插件。
我的建议尝试创建一个主包含文件,从中导入所有常用的内容。诸如登录/注销、数据库访问、Web 服务、JavaScript 库等。
一定要使用类。它们是超原始的(没有继承),但正如 jamting 所说,它们很方便。
正确缩进脚本。
评论
编写外部架构文档。我个人使用 LyX,因为它无法生成格式良好的 pdf,但你可以使用任何你喜欢的东西。如果您使用 wiki,请安装 graphviz 插件并使用它。制作可以轻松修改的快速图表非常容易。
由于我不知道增强功能需要多大程度,因此我建议拥有一份良好的高级到中级架构文档对于规划增强功能非常有用。
在业务逻辑单元测试中,我发现唯一有效的是在 asp 中设置一个 xml-rpc 侦听器,该侦听器导入主库并公开主库的任何子包含中的函数(尽管不是子例程),然后使用一种语言单独构建一个单元测试系统,该系统可以更好地支持通过 xml-rpc 调用 ASP 函数的内容。我使用 python,但我认为 Ruby 应该可以解决这个问题。(那有意义吗?)。最酷的是,编写软件单元测试部分的人甚至不需要查看 ASP 代码,只要他们对要调用的函数有适当的描述,所以他们可以是你身边的人。
有一个项目叫 阿斯普尼特 在 sourceforge 上,但最后一个版本是在 2004 年,并且它被标记为非活动状态。从未使用过它,但它是纯 vbscript。粗略地看一下代码,我发现作者似乎知道他们在做什么。
最后,如果您需要帮助,我可以做一些合同远程办公工作(最多每周 8 小时)。按照链接路径获取联系信息。
祝你好运!HTH。
其他提示
由于完全重写工作系统可能非常危险,我只能给您一个小提示:在您的项目上设置丰富的标签 ctags。这样你就可以跳转到函数的定义和子简单,我认为这有很大帮助。
关于将逻辑与“视图”分开。VBScript 支持某种带有类的 OO。我倾向于编写类来执行我包含在充当“视图”的 asp 页面上的逻辑。然后我将视图与用户名这样的类挂钩:<%= MyAccount.UserName %>。MyAccount 类还可以具有以下方法:MyAccount.Login() 等。
有点原始,但至少您可以封装一些代码并将其隐藏在 HTML 中。
我的建议是继续重构,经典 ASP 支持类,因此您应该能够将除显示代码之外的所有内容移动到仅包含类的包含 ASP 文件中。请参阅这篇文章,了解从老式 ASP 迁移到 ASP.NET 的详细信息
关于未来的方向,我不会瞄准 ASP.NET Web 表单,而是选择 Microsoft 的新 MVC 框架(ASP.NET 的附加组件)。从经典 ASP 迁移到此会简单得多。
您是否有机会从 ASP 迁移到 ASP.Net?或者您正在考虑将其保留在经典 ASP 中,但只是清理它。如果可能的话,我建议尽可能转向.Net。无论如何,看起来您可能正在重写/重新组织大量代码,因此迁移到 .Net 可能不需要太多额外的努力。
想必其他人编写了您现在维护的大部分或全部系统。寻找常见的坏习惯(重复的代码、范围太广的变量、嵌套的 if 语句等),然后像任何其他语言一样进行重构。留意同一文件或不同文件中重复出现的内容,并将它们抽象为函数。
如果代码是由不同的人编写/维护的,则可能会出现一些编码风格不一致的问题。我发现将代码重新排列起来可以更容易地看到可以重构的东西。
“数千行长”让我怀疑也可能存在松散相关的内容显示在同一页面上的情况。同样,您希望将它们抽象为单独的子例程。
最终,您希望编写对象来帮助封装数据库连接等内容,但需要一段时间才能实现。
这是很旧的,但忍不住加上我的两分钱。如果必须重写,并且必须继续使用经典ASP:
- 使用 JScript!更强大的是,您可以获得继承,并且有一些好的副作用,例如使用与客户端相同的方法进行服务器端验证
- 你绝对可以做MVC - 我写了一个MVC框架,而且代码行数并不多
- 您还可以通过一些工作自动生成模型类。我有一些代码运行得很好
- 确保您正在执行参数化查询,并始终返回断开连接的记录集
软件开发项目管理实践表明,此类软件需要退役。
我知道做正确的事是多么困难,尤其是当负责任的经理知道什么并且害怕除了可能的最坏方式之外的一切时。
但仍然。有必要开始开发新软件。永远维持这个记录根本不可能,而且他们等待记录器退役的时间越长,情况就越糟。
如果您没有适当的规范/需求文档(我认为世界上没有任何 ASP 软件可以做到这一点,考虑到这些编码员的菜鸟能力),您将需要一组了解软件功能的用户和一名经理负责验证要求。您需要检查每个功能并记录其要求。
在此过程中,您将了解有关该软件及其业务的更多信息。一旦获得足够的信息,您就可以开始开发新的。