问通过本地API重写旧的、损坏的桌面应用程序

EN

我们目前正在支持一个非常过时，非结构化，未经测试和不稳定的ERP桌面应用程序编码的温德夫( windows)。随着时间的推移，我们需要为用户添加更多的功能，但我们仍然会遇到可怕的错误、数据丢失和完整性问题。无论我们试图实现什么，以避免重写整个程序，都会不断失败，因为应用程序是如何构造的。

我的任务是找到一种方法，慢慢地合并到一个新的更干净的架构，而不需要关闭业务来完成重写。由于我们没有任何测试，而且代码不是要测试的，重构是非常危险的，因为我们没有任何安全网。

我们拥有的大多数bug都与数据相关，而且由于每个实体都是从各地访问的，因此很难修复数据问题或确保其健壮。我们运行ERP，所以我们销售的应该是可靠的数据。

我正在考虑的当前方法是，将所有内容慢慢地合并到一个后端API中，并在C#中使用一个健壮的结构。其计划是通过本地API对每个新的数据库进行访问，并逐步将现有数据合并到API中。由于当前资源是从整个应用程序中访问的，因此其中许多资源将部分迁移到API中，而部分资源仍将在Windev应用程序中硬编码，直到对某个实体/端点的所有访问都被完全迁移。

我在这里看到的好处是，我们将能够通过一个新的应用程序慢慢地合并，并最终集中所有数据访问，这将允许我们测试端点。这种方法的另一个优点是，如果我们决定开始重写，那么大部分繁重的工作就会完成，因为我们只需要转换一点业务逻辑并创建一个新的UI。如果我们决定仅仅通过托管API，我们甚至可以上网。客户端请求不会被阻止，因为我们只需要在API中传递新数据并将旧的数据访问合并到其中。

我看到了一些问题，包括在很长一段时间内支持应用程序和本地服务器将是一个痛苦的问题，而且我们可能会对性能产生一些影响，但我仍然认为积极的方面远远超过了坏的方面。

我是否完全疯了，用这种方法，我是不是错过了一些明显的更清洁的解决方案。

请记住，我们目前使用的编程语言具有一个完全封闭的生态系统，在这个生态系统中，我们只能使用它自己的部署工具，它是自己的查询语言和数据库，文档很少，而且它在清洁设计方面非常有限。甚至很难将OOP原理应用到它上，所以我们需要尽快摆脱这个生态系统。