你和 YAGNI 能走多远？[关闭]
https://stackoverflow.com/questions/2023638
-
19-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
我正在为企业市场开发一种新的革命性网络应用程序。当然，在我之前的许多人都认为他们的网络应用程序将是革命性的，但后来发现事实并非如此。（或者是，但是生意反正不好）。
所以我在想，为了找出我的想法是否能以最低的成本获得牵引力，遵循极端的 YAGNI：
没有安全功能（即没有用户等）。对于任何新客户，我都会安装一个新的数据库实例和一个新的 Web 应用程序实例。每个 webapp 实例都受到 http 服务器密码的保护（摘要或基本授权，可能通过 https）。
没有国际化。只是嵌入在源代码中的英文字符串。
没有解耦。只是与数据库对话的网页。
没有任何表演技巧。没有队列、缓存、计时器、后台作业、异步调用等。
没有可扩展性。没有数据库分区、没有分片、没有集群或复制。
此外，只要合适，就在微观层面使用 YAGNI。
我只是想启动该项目并尽快达到可以通过简单且引人入胜的用户界面出售（或尝试出售）我的创新功能的程度。
如果计划失败，我会早知道的。如果成功的话，我就会看到客户想要什么。他们想要法语版本吗？或者他们想要组织内的用户和角色？
这就是人们所说的YAGNI的意思吗？还是这是YAGNI病态的、夸张的例子？
解决方案
我完全同意 YAGNI 原则，但你仍然想为成功做好计划。如果一个应用程序在突然拥有十多个用户时需要完全重写，那么 YAGNI 就太过分了。
有些东西你会需要。从我的角度来看，最重要的有两点：
不要因为没有为应用程序国际化做好准备而搬起石头砸自己的脚。如果你的申请足够好，国际化总有一天会被提上台面。此外，在 2010 年从头开始构建应用程序时，使用 UTF-8 处理外来字符的能力是绝对要求。对于以英语为母语的人来说，国际化似乎并不那么重要，但相信我，它是必不可少的，而且以后国际化应用程序的痛苦是可怕的。
考虑一下没有安全功能的事情。如果组织或团体希望与不同安全级别的用户一起使用您的应用程序，该怎么办？它 可以 这是一个你真的可以不需要的功能 - 我的许多产品中内置了一个细粒度的安全系统，但尚未充分发挥其潜力。但请仔细考虑您的特定应用程序是否可以不使用，即使它是成功的。
其他提示
这就是他们所说的“原型设计”。大胆试试吧。
YAGNI 和原型设计之间存在微妙之处。
当用户要求功能性时，你说不，那就是 YAGNI。
当它实现时（国际化、“解耦”（？）、队列、缓存、计时器等），你对自己说不。那不是真正的YAGNI。这就是原型设计。
你这里的大部分内容似乎都不是以用户为导向的镀金。我不会准确地称之为“YAGNI”。
我本人并不喜欢 YAGNI 原则；我发现它经常被用来为设计不良的软件辩护。当然，过度设计的软件也是一个问题，但“YAGNI”并没有为实际影响分析留下太多空间。
事实证明，在软件世界中，许多您认为不需要的东西实际上是需要的。然后还有一些。谁是thunkkit。
我编写了一两个应用程序，这些应用程序应该是一次性应用程序或保留的应用程序，但两年后仍在生产中。维护它们很痛苦。
尤其是当涉及到安全之类的事情时 - 您可能 是 会需要它。
YAGNI 是一个很好的原则，但它不是唯一的设计原则。为了将产品快速呈现在用户面前，上述许多措施都是有意义的。但是，例如，如果直接与数据库对话的网页开始都有重复的代码，您将发现对一种原则（YAGNI）的盲目依赖而排除其他原则（在本例中为 DRY）将限制您的能力响应您希望不断增长的用户的功能请求。
如果你想真正开发一个 面向企业市场的革命性 Web 应用程序 我不太确定其中哪一个 是欧 A整数 G恩纳 氮需要。
而且你的例子也很具体。例如当你说：“没有安全功能”...我想说，用户可能是你可以做的一件事，但清理你的输入是你不能做的一件事。此外，“可扩展性”不是数据库分片或复制的问题，这些是您在意识到应用程序扩展性不佳后做出的决定。
我宁愿在使用时小心 亚格尼 作为高级设计指南，当您谈论奇怪的产品功能或软件组件的极端灵活性时，它是最合适的。
只是我的0.2
如果你把“YAGNI”推向极端（我会回避关于这是否是一个好主意的讨论，以及关于这是否真的是“YAGNI”的讨论），你应该准备好无情地重构你的代码库以添加稍后将您现在遗漏的内容放入其中，而无需创建泥球。
在我看来，YAGNI 最常用于开发人员思考“哦，如果我们还添加 X 功能，那就太聪明了”的情况。我们将来可能需要它。” 从来没有 曾经 添加不是必需的功能。
话虽这么说，如果您的客户认为功能 Y 是绝对必要的，那么您的代码应该始终开放进行修改。一个好的架构是必须的！
关于可扩展性、队列、缓存：这取决于。申请有什么要求？它是一个由 10 个并发用户使用的 Intranet 站点，还是一个拥有数百万用户的流行网站。这取决于。找到需求并执行——仅此而已。亚格尼。如果您的要求发生变化；更改您的应用程序 - 它应该开放进行修改。
YAGNI 很好，如果你有足够的机会的话 绝不 需要它。如果您现在不需要它，但您几乎确定在可预见的将来会需要它，那么提前安装它几乎总是比以后安装更容易。当你证明不实施你不需要的东西时 这一秒 但几乎肯定会在不久的将来需要 YAGNI，这就是问题开始的地方。
值得记住的是，亚格尼只是众多校长中的一位。有时，亚格尼会建议一个决定，但也有同样充分（或更好）的理由选择另一个决定。
我认为一些 YAGNI 支持者可能会在以下一个领域走得更远：如果您对 OOD/多态性感到满意，那么您通常只需花费很少的成本即可“烘焙”一些出色的扩展点以供将来使用，即使是在原型中也是如此。
这是一个例子...
您正在创建一个原型 Web 应用程序，其中包含显示报告的打印友好版本的功能。您需要快速工作，但有一种很好的感觉，牛排馆老板会要求能够通过电子邮件发送报告。
在服务器端 Java 代码中，隐藏正在为接口后面的打印机准备报告这一事实。创建一个扩展接口的具体类来承担该责任。实际上不要走开 写 界面的电子邮件版本，因为 YAGNI。但如果你这样做了，你就可以将其添加到现有的功能中，而不会造成任何破坏。
我想说的是，如果你一开始就抛弃所有常识并以尽可能最便捷的方式完成整个项目，那么你最终会得到一大堆失败......这绝不是革命性的。
如果您确实想知道它是否有用，请做一些屏幕模型。甚至可能只是普通的旧硬编码 html。将这些信息带给潜在客户，看看您是否可以迈入这一步。如果其中一些开始咬人，那就拼命建造它。
签订合同、获得付款并让客户员工真正开始使用它需要时间。在此过程中，构建它。
最有可能发生的情况是，潜在客户会看到您的应用程序，并希望告诉您为什么它不适合他们。更改模型并返回。根据需要进行迭代，直到您的产品有了有人愿意付费的前端设计。
我要做的是：
1) 设计时考虑到正确的架构决策。在这种情况下，国际化和安全性可能是必须的。
2）开发时，为稍后要实现的这些原则创建钩子。因此，当您有时间和预算时，您可以实施它们，而无需进行重大改造。
3) 然后您可以专注于那些能让您的应用程序顺利运行并且对您的潜在客户更重要的功能。
所以我认为在这种情况下我会更多地使用 KISS 方法而不是你建议的“极端 YAGNI”。
在我看来，应该默认遵循 YAGNI，因为它允许 大大提高生产力.
我想，也有一些例外。例如，如果您开发一个第三方库，您确实需要至少提前一点思考并预测一些未来用户的需求。这并不是说您必须完全放弃 YAGNI，但您不应该像内部开发那样严格遵循它。
对，但是...
我倾向于同意你的许多想法 除了 “无脱钩”，因为Yagni中的“ IT”代表功能，而不是思考步骤。引入一些抽象（仅是解耦所需的抽象）将立即从未犯错误或错误发现和删除的错误方面获得回报。
介绍这些抽象的一种很好的（因为它可以节省您的想法）将是 使用良好的网络框架，只需遵循其建议的应用结构样式.
作为附带的好处，添加以后的安全性，国际化，性能和扩展性的东西将变得更加容易，而您的Yagni-Behavior-Now应该变得相当安全。
（不幸的是，仅当您已经知道Web框架时，该参数才适用。在 YAGNI 王国，知识至高无上。）
