我提出需要重写旧的旧桌面应用程序。它是一个小型的非Java桌面程序，仍然支持几个内部用户社区的日常任务。
应用程序既过时又不再受支持的语言。我是初级开发人员，我需要重写它。为了避免app rewrite sinkhole，我计划开始使用现有数据库＆amp;数据结构（存在一些重大限制，但与重构一样痛苦，这种方法可以更快地完成初始工作，避免迁移，这两者都是成功的关键）。
我的挑战是，我对Keep It Simple的概念非常矛盾。我知道它是在谈论功能，而不是设计。但是当我期待编写这个应用程序时，似乎花费了大量的时间来追逐设计模式（特别是我真的在依赖注入方面苦苦挣扎）坚持好（但非 - ＆＃34;四人小组的设计可以更快，更简单地完成工作。
这个应用程序将会长大并存在很长时间，但它永远不会成为一个400万行的企业巨头，它的对象不会被另一个应用程序使用（是的，我知道，但如果.... YAGNI！）。
问题
KISS是否适用于建筑和设计？ ＆＃34;以后可以重构它吗？＃34;例如，规则应该扩展到＆＃34;我们将在以后回归依赖注入＆＃34;或者如果项目没有立即在所有所谓的关键框架支持中烘焙，那么该项目是否会自行完成？
我想这样做＆＃34;对＆＃34; ....但它也必须完成。如果我让它太复杂而无法完成，那么无论设计如何都会失败。
答案 0 :(得分：1)
我说KISS当然适用于建筑和设计。
在我的经验中，过度架构是一个常见的问题，并且存在与之相关的代码气味：
强制使用过于复杂的设计模式，更简单 设计就足够了。
如果使用更高级的设计模式，范例或体系结构不适合您的项目规模，请不要强迫它。
您必须权衡架构的潜在成本与潜在的节省量......但也要考虑为实现它所需的额外时间节省时间。
答案 1 :(得分：1)
是的，KISS，但请参阅http://www.amazon.com/Refactoring-Patterns-Joshua-Kerievsky/dp/0321213351并考虑以小步骤将重构为设计模式。代码应该告诉你该怎么做。