我需要重写旧的遗留桌面应用程序。它是一个小型的非 Java 桌面程序，仍然支持多个内部用户社区的日常任务。
应用程序已过时且不再受支持的语言。我是初级开发人员，我需要重写它。为了避免应用程序重写陷坑，我计划开始使用现有的数据库和数据结构（有一些重大限制，但与重构一样痛苦，这种方法将更快地完成初始工作，并且避免迁移，这两者都是成功的关键）。
我的挑战是我对保持简单的概念非常矛盾。我知道这是在谈论功能，而不是设计。但是当我打算编写这个应用程序时，似乎在坚持良好（但非“四人组”）的情况下，可能会花费大量时间来追踪设计模式（特别是我真的在依赖注入方面苦苦挣扎）设计可以更快、更简单地完成工作。
这个应用程序会成长并存在很长时间，但它永远不会成为一个拥有 400 万行的企业庞然大物，并且它的对象不会被另一个应用程序使用（是的，我知道，但是如果......YAGNI ！）。
问题
KISS 是否适用于建筑和设计？“稍后重构”规则是否可以扩展到说，例如，“我们稍后会回来进行依赖注入”，或者如果项目没有融入所有所谓的关键，那么项目是否注定要失败立即支持框架？
我想“正确”地做到这一点......但它也必须完成。如果我让它太复杂而无法完成，无论设计如何，它都会失败。