关于python：如果确定我们的系统需要大修，最好的方法是什么？

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

当前正在讨论两条路径：

使用JScript将现有的应用程序移植到Classic ASP，这将使我们希望从那里迁移到.NET MSJscript不会有太多麻烦，最终可以在.NET平台上使用(最好在那时用ASP完成MVC的工作)。在我们看来，NET并没有比我们现在更好。有人认为这是比下一个方案更安全，风险更低的方案，尽管可能需要更长的时间。

使用其他一些技术完全重写应用程序，现在，该包的领导者是具有定制框架，ORM和良好模板解决方案的Python WSGI。这里甚至还有django和其他预建解决方案的摆动空间。该方法有望成为最快的解决方案，因为我们可能会在实际产品旁边运行beta，但如果我们不能正确地做到这一点，它确实有可能浪费大量时间。

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

现在，这个问题。有没有人走过以上两条道路中的任何一条？如果是这样，它是否成功，它会如何更好？等等。我们并不想在做这两件事中有很大的偏离，但是一些建议或其他解决方案可能会有所帮助。

---

不要扔掉您的代码！

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

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

对于您的应用程序中的新功能，请用C＃编写，然后从经典ASP中调用它。重写此新代码时，您将被迫模块化。如果有时间，也可以将部分旧代码也重构为C＃，并逐步解决错误。最终，您将用所有新代码替换您的应用程序。

您也可以编写自己的编译器。很久以前，我们为经典的ASP应用程序编写了一个，以便我们输出PHP。这就是Wasabi，我认为这就是Jeff Atwood认为Joel Spolsky摆脱摇滚的原因。实际上，也许我们应该只运送它，然后您就可以使用它了。

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

另外，如果这是一个内部唯一的应用程序，则将其保留。不要重写它-您是唯一的客户，如果需要以经典asp的身份运行它，则可以满足该要求。

---

它的效果比您想象的要好。

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

它在类级别和整个应用程序级别通过了单元测试。遗留资源通常被用作" C语言规范"以发现真正晦涩的业务规则。

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

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

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

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

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

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

---

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

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

(我喜欢删除代码。)

---

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

---

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

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

对我有用的一般原则：

丢弃未使用或未注释掉的代码

丢弃所有无用的注释

定义应用程序的层层次结构(模型，业务逻辑，视图/控制器逻辑，显示逻辑等)。这不必是非常明确的体系结构，而应该帮助您考虑应用程序的各个部分，并帮助您更好地对代码进行分类。

如果某些内容严重违反了此层次结构，请更改有问题的代码。移动代码，在另一处重新编码，等等。与此同时，调整应用程序的其余部分以使用此代码，而不是旧代码。如果不再使用，则将旧的扔掉。

让您的API变得简单！

进度可能会非常缓慢，但应该值得。

---

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

---

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

---

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

---

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

---