如果决定对我们的系统进行改造，最佳方法是什么？
我们正在维护一个基于Classic ASP的网页应用，主要使用VBScript作为编程语言。大家都觉得我们的后台框架有点过时，无法提供我们快速前进所需的工具。我们已经基本接受了现在流行的webMVC模式，但用现有的技术实现起来比较困难。我们缺少的一些重要功能包括合适的调度和模板继承等。
目前我们在讨论两种方案：
- 将现有的应用程序迁移到使用JScript的Classic ASP，这样我们希望能顺利过渡到.NET的MSJscript，最终转到.NET平台（希望到那时候MVC的部分也能做好，毕竟我们觉得ASP.NET并没有比现在的情况好多少）。这个方案被认为是风险较小的安全路径，尽管可能需要花费稍长的时间。
- 完全重写应用程序，使用其他技术，目前最热门的选择是Python WSGI，配合自定义框架、ORM和良好的模板解决方案。这里还有空间可以考虑django等其他现成的解决方案。这个方法希望能是最快的解决方案，因为我们可能会在实际产品旁边运行一个测试版，但如果我们不能或不成功的话，也有可能浪费很多时间。
这并不意味着我们的逻辑就消失了，因为我们多年来构建的系统相对稳定，只是处理起来比较麻烦。它是建立在SQL Server 2005上，重度使用存储过程，并发布在IIS 6上，提供一点背景信息。
现在，问题来了。有没有人走过上述两条路径？如果有，结果如何？有什么可以改进的地方等等。我们不打算偏离这两种方案太远，但一些建议或其他解决方案可能会很有帮助。
9 个回答
结果比你想象的要好。
最近，我对一堆糟糕的旧C代码进行了大规模的逆向工程。一个一个功能地把仍然有用的部分重新整理成类，给这些类写了单元测试，然后构建了一个看起来像替代应用程序的东西。这个新应用程序保留了一些原来的“逻辑流程”，不过有些类设计得很糟糕[主要是因为有些全局变量太复杂，难以分开处理。]
这些类和整个应用程序的单元测试都通过了。旧的源代码基本上被当作一种“用C语言写的规范”，用来找出那些非常复杂的业务规则。
去年，我为替换30年前的COBOL写了一个项目计划。客户倾向于使用Java。我用Python和Django做了一个修订的数据模型原型，作为计划的一部分。在我完成计划之前，就能演示核心交易功能。
注意：在Django中构建模型和管理界面比整体规划项目要快。
由于“我们需要使用Java”的思维方式，最终的项目会比完成Django演示要大得多，成本也更高，但并没有真正的价值来平衡这笔费用。
此外，我还为一个需要转变为Web应用程序的VB桌面应用做了同样的“在Django中原型设计”。我在Django中构建了模型，加载了旧数据，几周内就搞定了。这个工作原型帮助我明确了后续的转换工作。
注意：我有一个可用的Django实现（只有模型和管理页面），用它来规划后续的工作。
在Django中进行这种原型设计的最好部分是，你可以随意调整模型、单元测试和管理页面，直到它们变得完美。一旦模型正确了，你就可以花时间调整用户界面，直到大家都满意为止。
把这个当作一个机会，去掉那些没用的功能！一定要选择新的语言。可以叫它2.0版本。重建你真正需要的80%的内容会轻松很多。
首先，把你对整个应用的记忆清空。坐下来列出它的总体目标，然后根据实际使用情况决定哪些功能是必要的。接着，围绕这些功能重新设计，然后开始构建。
(我喜欢删除代码。)
别把你的代码扔掉！
这是你在处理大项目时能犯的最糟糕的错误。可以看看你绝对不该做的事情，第一部分。
你在那段旧代码上花了很多心思，解决了不少问题。把它扔掉是开发者常犯的错误（我也犯过很多次）。虽然这样做让你感觉“轻松”了，就像大扫除一样。但你不需要为了整理房子而买个新公寓和全新的家具。你可以一间一间地整理……也许有些东西只需要重新刷漆而已。所以，这就是重构的意义所在。
如果你想在应用里增加新功能，可以用C#写新代码，然后从你的经典ASP中调用它。这样做会让你在重写新代码时不得不考虑模块化。当你有时间的时候，也可以把旧代码的一部分重构成C#，边重构边解决问题。最终，你就能用全新的代码替换掉整个应用。
你也可以自己写一个编译器。我们很久以前为我们的经典ASP应用写过一个编译器，让我们能输出PHP。这个编译器叫做Wasabi，我觉得这也是让Jeff Atwood觉得Joel Spolsky疯了的原因。其实，也许我们应该把它发布出来，这样你就可以使用了。
这个编译器让我们在下一次发布时可以把整个代码库切换到.NET，而只需重写很小一部分源代码。虽然这让很多人觉得我们疯了，但写一个编译器并不复杂，而且给了我们很大的灵活性。
另外，如果这是一个内部使用的应用，那就别动它。不要重写它——你就是唯一的用户，如果要求是必须以经典ASP运行，那你就可以满足这个要求。