Design patterns 你和雅格尼一起去了多远？

我正在为企业市场开发一个新的革命性web应用程序。当然，在我之前的很多人都认为他们的web应用程序是革命性的，但后来发现它不是。（或者是这样，但无论如何生意都不好）

因此，我在想，为了找出我的想法是否具有最低成本的吸引力，遵循极端的雅格尼：

• 没有安全功能（即没有用户等）。对于任何新客户，我都会安装一个新的数据库实例和一个新的webapp实例。每个webapp实例都由http服务器密码（摘要或基本授权，可能通过https）保护

• 没有国际化。源代码中只嵌入了英文字符串

• 没有脱钩。只是与数据库对话的网页

• 没有表演技巧。没有队列、缓存、计时器、后台作业、异步调用等

• 没有可伸缩性。没有数据库分区，没有碎片，没有集群或复制

• 此外，只要合适，在微观层面上使用YAGNI

我只想开始这个项目，并尽快达到一个点，我可以出售（或尝试出售）我的创新功能与一个简单和迷人的用户界面

如果计划失败，我会早知道的。如果成功的话，我会看看客户想要什么。他们想要法文版的吗？或者他们想要组织内的用户和角色

这就是人们所说的雅格尼，还是雅格尼的病态和夸张的例子？

这就是他们所说的“原型”。去做吧

雅格尼和原型设计之间有微妙之处

当用户请求featuritis时，您说不，这就是YAGNI

当它是实现（I18N，“解耦”（？）、队列、缓存、计时器等）时，您对自己说不。那不是真正的雅格尼。这就是原型

---

这里的大部分内容似乎不是面向用户的镀金。我不会称之为——确切地说——雅格尼。雅格尼是一个好的原则，但它不是唯一的设计原则。以上许多都有助于快速将产品展示在用户面前。但是，例如，如果直接与数据库对话的网页开始出现重复的代码，您将发现对一个原则（YAGNI）的盲目依赖而排斥其他原则（在本例中为DRY）这将限制您对希望不断增长的用户功能请求做出响应的能力。

我完全同意YAGNI原则，但您仍然希望为成功做好计划。如果一个应用程序突然有超过10个用户时需要完全重写，那么就太过分了

一些你需要的东西。在我看来，最重要的两点是：

• 不要因为你的应用程序没有准备好国际化而伤到自己的脚。如果你的应用程序很好，国际化总有一天会出现。此外，在2010年从头开始构建应用程序时，使用UTF-8处理外来字符的能力是绝对必要的。国际化对一个以英语为母语的人来说似乎并不重要，但相信我，国际化是必不可少的，而且以后将应用程序国际化的痛苦是可怕的

• 对没有安全功能的事情要三思而后行。如果某个组织或组希望与不同安全级别的用户一起使用您的应用程序，该组织或组会如何处理。这可能是一个你真的可以不使用的功能——我的许多产品都内置了一个细粒度的安全系统，它从未被充分利用过。但是，请仔细考虑您的特定应用程序是否可以不使用它，即使它是成功的

---

在我看来，YAGNI最常用于开发人员认为“如果我们还添加了功能X，那将是明智的。我们将来可能需要它。”永远不要添加不需要的功能

也就是说，如果您的客户认为特性Y是绝对必要的，那么您的代码应该始终开放供修改。一个好的架构是必须的

---

关于可伸缩性、队列、缓存：这取决于。申请的要求是什么？它是一个由10个并发用户使用的内部网站，还是一个拥有数百万用户的流行网站。视情况而定。找到需求并这样做——仅此而已。雅格尼。如果您的需求发生变化；更改您的应用程序-它应该可以打开进行修改。

YAGNI提醒您了解您可以做什么和需要做什么来满足您的需求之间的差异

例如，如果您的要求是“让人们创建帐户并登录”，只需使用框架的默认身份验证方法，然后继续下一个要求

您的web应用程序可以支持OpenID、Active Directory、本地数据库、平面文件和无数其他类型的身份验证方法，但您可以通过实现最简单的方法来满足要求。（对我来说，暗示）

“只要有足够的时间，我什么都能做”

-我见过的每个程序员

---

如果你真的要为企业市场开发一个革命性的web应用程序，我不确定你不需要这些东西中的哪一个

你的例子也很具体。例如，当你说：“没有安全功能”。。。我想说，用户是一件你可以不用做的事情，但对你的输入进行消毒是一件你不能做的事情。此外，“可伸缩性”不是数据库分片或复制的问题，这些是您在意识到应用程序不能很好地扩展后所做的决定

当使用雅格尼作为高级设计指南时，我宁愿小心，当您谈论古怪的产品功能或可能是软件组件的极端灵活性时，它最适合

---

只有我自己的0.2不喜欢雅格尼原则；我看它用得太多了