我们有一个现有的“遗留”应用程序，用 C++/powerbuilder 编写，在 Unix 上运行，带有自己的 Sybase 数据库。对于复杂的组织（现有应用程序必须经过大量繁文tape节才能修改）和代码原因（多年来没有进行重构，因此代码是意大利面条），因此很难对这个应用程序进行修改。因此，我正在考虑编写一个新的基于 grails 的现代 Web 应用程序来直接在数据库中执行一些“管理”类型的事情。例如添加用户，或添加“约束行”。
软件社区如何看待这种围绕现有应用程序运行的方法？好主意？提示和提示？
【问题讨论】：
标签： c++ architecture grails refactoring
在一个单一的应用程序和几个更专注的应用程序之间总是存在争论。我认为将事物分开不一定是一个坏主意-您使事物更加模块化，减少依赖性等。要避免的是功能重复。如果您单独拆分管理应用程序，请确保从旧应用程序中删除该功能，否则您将拥有一组未维护的管理工具，这些工具可能会再次困扰您。
【讨论】：
好主意？没有。
有时需要？是的。
生活在一个有时不得不做一些你知道不是好主意的事情的世界里？无价之宝。
一般来说，您应该始终遵循最佳做法。对于其他所有内容，都有杂项。
【讨论】：
请首先查看来自 Joel 的 this！
更新：我有点误解了这个问题，并认为更多内容正在被重写。
我对您建议的“实用程序”系统的看法并不像我对 Joel 文章的链接所暗示的那样保留。事实上，出于多种原因，我衷心建议您采用这种方法。
首先，这很可能是达到您想要的结果的最快途径，因为旧代码很难使用。
其次，这可以让您体验新的开发技术，并在您现有工作的背景下这样做 - 这是一个真正的优势。
第三，几年前我在将应用程序从 C++ 转换到 Delphi 时采用了这种方法。随着时间的推移，Delphi 应用程序变得如此强大，以至于可以完全飞跃到该平台。用户在任何时候都不会缺少他们已经知道的功能，因为在替换功能得到验证之前，旧应用程序不会被淘汰。但是，在这个阶段，您需要注意 Joel 的警告：请记住，您看到的一些“混乱”实际上是旧代码中包含的知识。
【讨论】：
好主意？这取决于数据库的记录和/或理解程度。对某些隐式应用程序级实现的规则、关系或约束犯了一个错误，您的旧应用程序最终可能会在过道上翻车。
举一个假设的例子。假设使用旧系统添加用户会将记录添加到以下表格中：
假设您抓住了前三个，错过了第四个。不可能很重要吧？但是，如果在应用程序中，在使用 app_users 的 50 个位置中，有一个位置与 user_address 进行了内部连接。 （为什么不呢？应用程序编写者知道他总是向 user_address 写入一条记录！）新添加的用户突然从应用程序的视图中消失，根据原始编码员的说法，这种情况“永远不会发生” ，并且应用程序会咳出一个毛球。不能接受订单。生产停止。一位副总裁对他的新心脏搭桥手术进行了测试。
谁会受到指责？不是应该为更多异常编写代码的早已离开的开发人员。不是那些设置繁文缛节来控制变化的人。完成任务的人绕过这些控件。
祝你好运，
特里。
【讨论】：