32

我正在为企业市场开发一个新的革命性 Web 应用程序。当然，在我之前的许多人都认为他们的网络应用程序将是革命性的，结果发现事实并非如此。（或者是，但反正生意不好）。

所以我在想，为了找出我的想法是否有任何成本最低的牵引力，遵循一个极端的 YAGNI：

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

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

  • 没有解耦。只是与数据库对话的网页。

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

  • 没有可扩展性。没有数据库分区、没有分片、没有集群或复制。

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

我只是想开始这个项目，并尽可能快地达到我可以通过简单且引人入胜的 UI 销售（或尝试销售）我的创新功能的地步。

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

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

4

14 回答 14

39

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

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

  • 不要因为没有为应用程序国际化做好准备而自取其辱。如果您的应用程序有任何好处，那么国际化总有一天会出现。此外，在 2010 年从头开始构建应用程序时，使用 UTF-8 处理外来字符的能力是绝对要求。国际化对于以英语为母语的人来说似乎并不那么重要，但相信我，这是必不可少的，也是国际化的痛苦后来的申请太可怕了。

  • 对没有安全功能的事情三思而后行。想要与不同安全级别的用户一起使用您的应用程序的组织或组呢？可能这是您真正可以不用的功能 - 我的许多产品中都内置了细粒度的安全系统，但尚未充分发挥其潜力。但是请仔细考虑您的特定应用程序是否可以不用，即使它成功了。

于 2010-01-07T21:09:03.493 回答
17

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

YAGNI 和原型设计之间存在微妙之处。

  1. 当它是用户请求的功能炎，而你说不时，那就是 YAGNI。

  2. 当它实现时（I18N，“解耦”（？），队列，缓存，定时器等），你对自己说不。那不是真正的 YAGNI。这就是原型设计。

您在这里拥有的大部分内容似乎都不是面向用户的镀金。我不会称之为——确切地说——YAGNI。

于 2010-01-07T21:06:08.743 回答
9

YAGNI 是关于提醒您了解您可以做什么和需要做什么以满足您的要求之间的区别。

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

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

“只要有足够的时间，我可以做任何事”

- 我见过的每个程序员

于 2010-01-07T21:14:52.360 回答
6

我自己不是 YAGNI 原则的粉丝；我发现它经常被用于为设计不佳的软件辩护。过度设计的软件当然也是一个问题，但是“YAGNI”并没有真正为实际影响分析留下太多空间。

事实证明，在软件的世界里，许多你认为不需要的东西，实际上是需要的。然后还有一些。谁大通吉特。

我已经编写了一两个应用程序，这些应用程序应该是一次性应用程序或两年后仍在生产中的保留应用程序。维护它们很痛苦。

尤其是涉及到安全性之类的东西时——你可能会需要它。

于 2010-01-07T21:15:27.927 回答
3

YAGNI 是一个很好的原则，但它不是唯一的设计原则。上述许多内容对于快速将产品呈现在用户面前是有意义的。但是，例如，如果直接与数据库对话的网页开始每个都有重复的代码，你会发现盲目地依赖一个原则（YAGNI）而排斥其他原则（在这种情况下是 DRY）会限制你的能力响应您希望不断增长的用户的功能请求。

于 2010-01-07T21:08:51.123 回答
3

如果您要真正为企业市场开发一个革命性的Web 应用程序，我不确定您需要哪些东西。

你的例子也很具体。例如，当您说：“没有安全功能”时......我会说用户是您可能没有的一件事，但清理您的输入是您做不到的。此外，“可扩展性”不是数据库分片或复制的问题，这些是您在意识到您的应用程序无法很好地扩展后做出的决定。

在将YAGNI用作高级设计指南时，我宁愿小心，当您谈论奇怪的产品功能或软件组件的极端灵活性时，它最适合。

只是我的 0.2

于 2010-01-07T21:15:16.503 回答
3

如果你把“YAGNI”带到那个极端（我将回避关于这是否是一个好主意的讨论以及关于这是否真的是“YAGNI”的讨论），你应该准备好无情地重构你的代码库以添加稍后您现在省略的内容没有创建泥球。

于 2010-01-07T21:18:01.117 回答
2

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

话虽如此，如果您的客户认为功能 Y 是绝对必要的，您的代码应该始终开放以供修改。一个好的架构是必须的！

关于可扩展性、队列、缓存：这取决于。申请有什么要求？它是一个被 10 个并发用户使用的 Intranet 站点，还是一个拥有数百万用户的流行网站。这取决于。找到要求并做到这一点 - 仅此而已。雅尼。如果您的要求发生变化；更改您的应用程序 - 它应该可以修改。

于 2010-01-07T21:13:58.863 回答
2

如果有一个不错的机会你永远不需要它，YAGNI 就很好。如果您现在不需要它，但您几乎可以肯定在可预见的将来会需要它，那么预先安装它几乎总是比以后更容易。当你证明不实施你现在不需要但几乎可以肯定在不久的将来 YAGNI 需要的东西时，这就是问题开始的地方。

于 2010-01-07T21:19:47.370 回答
2

YAGNI 只是众多校长中的一位，这一点值得记住。有时 YAGNI 会建议一个决定，但也有同样好的（或更好的）理由偏爱另一个。

这是我认为一些 YAGNI 支持者可能会走得更远的一个领域：如果您对 OOD/多态性感到满意，那么“烘焙”一些用于未来使用的出色扩展点通常花费很少，即使在原型中也是如此。

这是一个例子......

您正在创建一个原型 web 应用程序，其中包括显示报表的打印友好版本的能力。您需要快速工作，但有一种很好的感觉，牛排负责人会要求能够通过电子邮件发送报告以及下线。

在您的服务器端 Java 代码中，隐藏报表正在为接口后面的打印机准备这一事实的知识。创建一个扩展接口以承担该责任的具体类。不要真的去写界面的电子邮件版本，因为 YAGNI。但是，如果您这样做了，那么您就可以将其添加到现有功能中而不会造成大屠杀。

于 2010-01-07T21:24:05.410 回答
2

我想说的是，如果您一开始就抛弃所有常识，并以最方便的方式完成整个项目，那么您最终会遇到一大堆失败……这绝不是革命性的（ Tm值）。

如果您真的想知道它是否有用，请做一些屏幕模型。甚至可能只是普通的旧硬编码 html。把这些带到潜在客户那里，看看你能不能踏上门。如果他们中的一些人开始咬人，那就打断你的屁股并建造它。

签订合同、获得付款并让客户工作人员中的某个人真正开始使用它需要时间。在此过程中，构建它。

最有可能发生的事情是潜在客户会看到您的应用程序，并希望能告诉您为什么它不适合他们。更改模型并返回。根据需要进行迭代，直到您为您的产品设计出有人愿意支付的前端设计。

于 2010-01-07T21:30:05.243 回答
1

我会做的是：

1) 设计时考虑到正确的架构决策。在这种情况下，国际化和安全性可能是必不可少的。

2）在开发时，为这些原则创建钩子，以便以后实现。因此，当您有时间和预算时，您可以在不进行重大改造的情况下实施它们。

3) 然后，您可以专注于使您的应用程序运行起来并且对您的潜在客户更重要的功能。

所以我认为在这种情况下，我会使用更多的 KISS 方法，而不是你建议的“极端 YAGNI”。

于 2010-01-07T22:56:54.197 回答
1

In my opinion, YAGNI should be followed by default as it allows for boosting productivity greatly.

There are some exceptions, thought. For example, if you develop a 3rd party library, you do need to think at least a little bit ahead of time and anticipate some future users' needs. That is not to say that you have to give up on YAGNI completely, but you shouldn't follow it as strictly as with an in-house development.

于 2015-06-11T12:42:46.810 回答
0

对，但是...

除了“无解耦”之外，我倾向于同意您的许多考虑，因为 YAGNI 中的“它”代表功能，而不是思考步骤。引入一些抽象（只是解耦所需的）将立即在错误未发生或错误更快发现和删除方面得到回报。

引入这些抽象的一个好方法（因为它可以节省您的思考）是使用一个好的 Web 框架并简单地遵循其建议的应用程序结构风格。

作为附带的好处，以后添加安全性、国际化、性能和扩展性的东西会变得容易得多，并且你的 YAGNI 行为现在应该变得相当安全。

(Unfortunately, the argument applies only if you know the web framework already. Knowledge reigns supreme in YAGNI kingdom.)

于 2014-09-24T14:06:24.120 回答