我正在为企业市场开发一个新的革命性Web应用程序。当然，很多人在我之前认为他们的网络应用程序将是革命性的，只是发现它不是。 （或者它是，但无论如何业务都不好）。
所以我在想，为了找出我的想法是否有最低成本的牵引力，遵循极端的YAGNI：
没有安全功能（即没有用户等）。对于任何新客户，我安装了一个新的数据库实例和一个新的webapp实例。每个webapp实例都受到http服务器密码（摘要或基本授权，可能通过https）的保护。
没有国际化。只是嵌入在源代码中的英文字符串。
没有脱钩。只是与数据库通信的网页。
没有表演技巧。没有队列，缓存，定时器，后台作业，异步调用等。
没有可扩展性。没有数据库分区，没有分片，没有群集或复制。
此外，只要合适，就可以在微观层面使用YAGNI。
我只是想开始这个项目并尽可能快地达到我可以通过简单而引人入胜的UI销售（或尝试销售）我的创新功能的地步。
如果计划失败，我会尽早知道。如果成功，我会看到客户想要的东西。他们想要法语版吗？或者他们是否想要组织内的用户和角色？
这是人们对YAGNI的意思，还是这是YAGNI的一个病态和夸大的例子？
答案 0 :(得分：37)
我完全同意YAGNI的原则，但你仍然想要成功的计划。如果一个应用程序突然有超过十个用户需要完全重写，那么它的YAGNI就太过了。
你需要的一些东西。从我的角度来看，最重要的两点是：
不要准备你的应用程序进行国际化，不要让自己陷入困境。如果您的申请有任何好处，那么国际化将在某一天出现在桌面上。此外，在2010年从头开始构建应用程序时，使用UTF-8处理外来字符的能力是绝对必要的。国际化对英语母语人士来说似乎并不重要，但相信我，这是必不可少的，国际化的痛苦以后的申请很可怕。
三思而后行无安全功能。那些想要与不同安全级别的用户一起使用您的应用的组织或团体怎么办？ 可以这是一个你可以真正做到的功能 - 我的许多产品中都内置了一个细粒度的安全系统，但从未充分利用它。但要好好考虑一下你的具体应用是否可以做到，即使它是成功的。
答案 1 :(得分：17)
这就是他们所谓的“原型制作”。去吧。
YAGNI与原型制作之间存在微妙之处。
如果是用户要求的特征性炎症，你说不，那就是YAGNI。
当它实现时（I18N，“解耦”（？），队列，缓存，定时器等）并且你对自己说不。那不是YAGNI。这是原型设计。
这里的大部分内容似乎都不是面向用户的镀金。我不会这称呼 - 正是 - YAGNI。
答案 2 :(得分：9)
YAGNI旨在提醒您注意您可以所做的事情与您需要做些什么来满足您的要求之间的区别。
例如，如果您的要求是“让人们创建帐户并登录”，那么只需使用框架的默认身份验证方法，然后继续执行下一个要求。
您的网络应用可以支持OpenID，Active Directory，本地数据库，平面文件以及其他各种身份验证方法，但您可以通过实施最简单的方法来满足要求。 （对我而言，YAGNI暗示DTSTTCPW）。
“如果有足够的时间，我可以做任何事情”
- 我见过的每一位程序员
答案 3 :(得分：6)
自己不是YAGNI原则的粉丝;我认为在设计不佳的软件的合理性中经常使用它。过度设计的软件当然也是一个问题，但“YAGNI”并没有给实际的影响分析留下太多空间。
事实证明，在软件世界中，许多您认为不需要的东西，实际上是您需要的。然后还有一些。 Who'dathunkit。
我已经写了一两个应用程序，应该是一次性应用程序或两年后仍在生产中的保留。他们很难维持。
特别是当涉及安全性时 - 你可能 需要它。
答案 4 :(得分：3)
YAGNI是一个很好的原则，但它不是唯一的设计原则。上述许多内容对于快速将产品放在用户面前是有意义的。但是，例如，如果直接与数据库对话的网页开始都有重复的代码，那么你会发现对一个原则（YAGNI）的盲目依赖而排除其他原则（在这种情况下为DRY）会限制你的能力回应您希望增加的用户功能请求。
答案 5 :(得分：3)
如果您要真正为企业市场开发革命性的Web应用程序，我不确定这些事情中的哪一个 Y ou A int G onna N eed。
此外，您的示例非常具体。例如，当你说：“没有安全功能”......我会说用户是你可以做的一件事，但是你不能对你的输入进行消毒。此外，“可伸缩性”不是数据库分片或复制的问题，而是在您意识到应用程序无法很好地扩展后所做的决定。
在使用 YAGNI 作为高级设计指南时，我会非常小心。当您谈论奇怪的产品功能或软件组件的极大灵活性时，它最适合。
只是我的0.2
答案 6 :(得分：3)
如果你把“YAGNI”带到那个极端（我将回避关于这是否是一个好主意的讨论，以及关于这是否真的是“YAGNI”的讨论），你应该准备好无情地重构你的代码库，以便稍后添加您现在遗漏的内容而不创建泥球。
答案 7 :(得分：2)
在我看来，YAGNI最常用于上下文中，开发人员认为“如果我们还添加了功能X，那将会很聪明。我们将来可能会需要它。”永远永远添加非要求的功能。
如果您的客户认为功能Y是绝对必要的，那么您的代码应始终打开以进行修改。一个好的建筑是必须的！
关于可伸缩性，队列，缓存：它取决于。申请的要求是什么？它是由10个并发用户使用的内部网站点，还是具有数百万用户的流行网站。这取决于。找到要求并做到这一点 - 仅此而已。 YAGNI。如果您的要求发生变化更改您的申请 - 应该可以修改。
答案 8 :(得分：2)
YAGNI是好的，如果有一个很好的机会你从不需要它。如果你现在不需要，但几乎可以肯定你在可预见的将来会需要它，那么将它装在前面比以后更容易。如果你没有实现你不需要这第二次的事情，但在不久的将来几乎肯定需要YAGNI，那就是问题开始的地方。
答案 9 :(得分：2)
YAGNI只是其中一位伟大的校长，这是一个值得记住的好人;有时YAGNI建议做出一个决定，但同样有好的（或更好的）理由更喜欢另一个。
这里有一个我认为YAGNI支持者可能会走得太远的地方：如果你对OOD /多态性感到满意，那么即使在原型中，为了将来使用而“烘烤”一些很好的扩展点通常也会花费很少
这是一个例子......
您正在创建一个原型webapp，其中包括显示报表的打印版本的功能。您需要快速工作，但感觉非常好，牛排持有人会要求能够通过电子邮件发送报告。
在服务器端Java代码中，隐藏了为接口后面的打印机准备报表这一事实的知识。创建一个扩展接口的具体类来承担该责任。实际上并不是写接口的电子邮件版本，因为YAGNI。但是，如果你曾经这样做，你就可以在没有大屠杀的情况下将它添加到你现有的功能中。
答案 10 :(得分：2)
我想说如果你开始抛弃所有常识并以尽可能最快的方式完成整个项目，那么你最终会遇到的是一大堆失败......这是不是意味着革命（tm）。
如果您真的想知道它是否有用，请做一些屏幕模拟。也许只是常规的旧硬编码的HTML。把它们带给潜在的客户，看看你是否可以踏上门。如果他们中的一些人开始咬人，那么就把你的屁股弄脏并建造它。
需要时间来签订合同，获得付款，并让客户工作人员真正开始使用它。在这种情况下，继续构建它。
最有可能发生的事情是，潜在客户会看到您的应用，并希望告诉您为什么它对他们不起作用。更改模拟并返回。根据需要进行迭代，直到您为自己的产品设计了一个愿意支付费用的前端设计。
答案 11 :(得分：1)
我要做的是：
1）设计考虑正确的架构决策。在这种情况下，国际化和安全可能是必须的。
2）开发时，为稍后要实现的原则创建钩子。因此，当您有时间和预算时，您可以在不进行重大改造的情况下实施它们。
3）然后，您可以专注于使您的应用程序飞起来的功能，并对您的潜在客户更重要。
所以我认为在这种情况下，我会使用更多的KISS方法而不是你所建议的“极端YAGNI”。
答案 12 :(得分：1)
在我看来，YAGNI应该默认为boosting productivity greatly。
有一些例外，想一想。例如，如果您开发第三方库，则需要至少提前考虑一下并预测未来的某些用户＆＃39;需要。这并不是说你必须完全放弃YAGNI，但是你不应该像内部开发一样严格遵守它。
答案 13 :(得分：0)
我倾向于同意你的许多注意事项除了“没有脱钩”， 因为YAGNI中的“它”代表功能，而不是思考步骤。 引入一些抽象（只是解耦所需的抽象）将会 在未发生错误或更快发现错误方面立即付清 并删除。
很好（因为它可以节省你的思考）引入这些抽象的方法 将使用一个好的Web框架，并按照其建议的应用程序 结构风格。
作为附带福利，添加安全性会变得更加容易， 之后的国际化，性能和扩展 而你的YAGNI行为现在应该变得相当安全。
（不幸的是，只有你知道这个论点才适用 网络框架已经。 知识在YAGNI王国中占主导地位。）