你对YAGNI原则的执行程度有多深入？

Question

我正在开发一款面向企业市场的全新革命性Web应用程序。当然，许多人之前也认为他们的Web应用程序是革命性的，结果发现它并不是这样的。（或者它确实是革命性的，但业务仍然不好）。

所以我在思考，为了以最低成本找出我的想法是否有吸引力，要遵循极端的YAGNI原则：

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

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

• 没有解耦。只有与数据库交互的网页。

• 没有性能技巧。没有队列、缓存、定时器、后台作业、异步调用等。

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

• 此外，在适当的情况下，采用微观级别的YAGNI方法。

我只想开始这个项目，并尽快达到一个点，以便可以通过简单而引人入胜的用户界面销售（或试图销售）我的创新功能。

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

这是人们所说的YAGNI意思吗？还是这是一种病态和夸张的YAGNI例子？

- flybywire

---

YAGNI的意思是“你不会需要它”。在软件开发中，这个原则建议避免在产品中增加不必要的功能或代码，因为它们只会浪费时间和资源。相反，应该专注于实现当前需要的功能，并将代码保持简洁。 - Alix Axel

YAGNI：你未来可能需要改进，所以至少考虑一下（但不要实现）某些东西在未来可能需要如何更改。 - Roger Pate

尽管Twitter曾出现过“鲸鱼翻车”的情况，但它目前非常受欢迎。如果他们一直等到拥有完美的高性能系统才发布，可能就永远无法大获成功了。 - Peter Recore

听起来像是提问者试图依赖一种流行的设计方法论作为懒惰的借口。我相信这对他来说会非常有效。 - Chris

只要做得正确，懒惰和尽可能少做事情并没有什么问题。 - Pekka

Answer 1

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

一些你必须要的东西。从我的角度来看，两个最重要的点：

• 不要因为没有为您的应用程序进行国际化准备而自食其果。如果您的应用程序足够好，国际化将在某一天成为可能。此外，使用UTF-8处理外文字符是从零开始构建应用程序的绝对要求。对于以英语为母语的人来说，国际化似乎并不那么重要，但请相信我，它是至关重要的，而后期国际化应用程序的痛苦是可怕的。

• 三思而后行，再考虑一下不加安全功能的事情。例如一个组织或团体想要与具有不同安全级别的用户合作使用您的应用程序，这可能是一个你真正不需要的功能 - 我在许多产品中构建了一个精细的安全系统，但它从未充分利用。但请认真考虑您的特定应用程序是否可以没有它，即使它很成功。

- Pekka

---

我希望我能给予多次赞同。安全和国际化是必须从一开始就考虑到的两个因素。它们后期添加几乎是不可能的，因为你总会漏掉某些东西（特别是在安全方面，这非常严重）。 - rmeador

Answer 2

这就是所谓的“原型制作”。加油。

YAGNI和原型制作之间存在微妙的差别。

1. 当用户请求了某项功能，你拒绝时，那就是YAGNI。

2. 当它是实现（I18N，“解耦”(?),队列，缓存，定时器等）时，你对自己说不。这并不是真正的YAGNI。这是原型制作。

这里大部分内容似乎并不是面向用户的过度设计。我不会完全称之为YAGNI。

- S.Lott

---

只有当他计划扔掉原型时，这才是原型制作。如果他计划保留并继续添加新功能，则这只是差劲的设计 :) - Eric Petroelje

@Eric Petroelje：（1）原型设计并不意味着你必须将其丢弃。许多增量开发方法都是从简单的解决方案开始，然后逐步添加功能。（2）我怀疑他为第一个版本提出的任何内容实际上都无法保留。 - S.Lott

原文：Prototypes often live forever翻译：原型通常会永久存在。 - Seth

我不同意（2）中的观点。当你对自己说“不”的时候，大多数情况下也是YAGNI。也许你想为类添加额外的方法“以防万一”，或者过载其他方法以防将来的用户需要它们。 - Pablo Fernandez

我很惊讶还没有人引用弗雷德·布鲁克斯的话:D“因此，管理问题不在于是否建立一个试验系统并将其丢弃。你会这样做。唯一的问题是是否提前计划建立一个可丢弃的系统，或者承诺向客户交付可丢弃的系统。”

• 弗雷德里克·P·布鲁克斯 Jr.

- CodeMonkey

Answer 3

YAGNI的意思是提醒您看到您可以做什么和满足您需求所需做什么之间的区别。

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

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

“只要给我足够的时间，我就能做任何事情” - 我遇到过的每个程序员

- Seth

Answer 4

我本人不喜欢YAGNI原则；我发现它经常被用来为设计不良的软件辩护。当然，过度设计的软件也是一个问题，但是“YAGNI”并不能留下实际影响分析的余地。

事实证明，在软件世界中，许多你认为不需要的东西，实际上你是需要的。然后更多一些。谁能想到呢。

我写了一两个应用程序，本来应该是一次性应用程序或者暂时使用的，但两年后仍在生产中。它们很难维护。

特别是在涉及安全方面时-您可能确实需要它。

- Aaronaught

Answer 5

YAGNI是一个好的原则，但它不是唯一的设计原则。许多原则都很有道理，可以快速让产品面向用户。但是，如果例如直接与数据库交互的网页开始出现重复代码，你会发现过度依赖某个原则（比如YAGNI），而排除其他原则（在这种情况下是DRY）将限制您应对用户功能请求的能力，特别是希望用户数量增长的情况下。

- mattjames

Answer 6

如果你要真正开发一款为企业市场而设计的革命性Web应用程序，我真的不确定哪些东西是必要的。此外，你的例子非常具体。例如当你说“没有安全功能”时，我认为你可以没有用户，但不能没有输入过滤。另外，“可扩展性”并不是数据库分片或复制的问题，这些决策是在意识到你的应用程序无法很好地扩展后做出的。在使用YAGNI作为高级设计指导方针时，我更愿意谨慎一些，它最适合谈论奇怪的产品特性或可能是软件组件的极端灵活性。这只是我的0.2个观点。

- Pablo Fernandez

Answer 7

如果你把"YAGNI"的理念推到极致（我将不讨论这是否是个好主意，也不讨论这是否真正符合"YAGNI"），那么你应该准备无情地重构你的代码库，在现在留下的空缺中后面再添加内容，而不会创建一团乱麻。

- quentin-starin

---

这意味着你需要从一开始就进行良好的自动化测试，否则在重构过程中试图防止回归将会让你发疯。 - drxzcl

我不同意。这只会增加最初发布的时间，而且我预计重构通常会是重要类中破坏API的变化，因为时间没有用于设计稳定的接口。 - quentin-starin

Answer 8

在我看来，“YAGNI”最常用于开发者的思考背景中，即“如果我们还添加功能X，那就很聪明了。我们将来可能会需要它。”千万不要加入任何不是需求的功能。

话虽如此，如果您的客户认为功能Y是必要的，那么您的代码应该始终开放进行修改。良好的架构是必须的！

关于可伸缩性、队列和缓存：这取决于应用程序的需求。它是一个被10个并发用户使用的内部网站，还是一个有数百万用户的热门网站？这取决于具体情况。找到需求并且只做这个 - 没有更多。YAGNI。如果您的需求发生变化，则改变您的应用程序 - 它应该是可以修改的。

- Tim Skauge

Answer 9

如果有相当大的可能性您永远不需要它，那么YAGNI原则是好的。 如果您现在不需要它，但几乎可以确定将来会需要它，那么从一开始就容易将其整合进去，而不是以后再添加。 当您通过YAGNI来证明不实施您现在不需要但几乎肯定会在不久的将来需要的事情时，问题就出现了。

- dsimcha

Answer 10

YAGNI只是众多重要原则之一，需要记住这一点。有时候YAGNI可能会建议一种决策，但同样有好的（或更好的）理由选择另一种方式。在我看来，有些YAGNI支持者可能会过分强调：如果你熟悉OOD/多态性，即使在原型中，为将来使用“内置”一些出色的扩展点通常代价很小。以下是一个例子：你正在创建一个原型Web应用程序，其中包括显示报告的打印友好版本的功能。你需要快速工作，但对于利益相关者将来可能会要求电子邮件报告的能力有很好的预感。在您的服务器端Java代码中，隐藏准备打印报告的事实背后的知识，并创建一个具体类来扩展该接口以承担该责任。不要实际撰写电子邮件版本的接口，因为YAGNI。但是，如果您真的需要，您可以轻松添加它而不会破坏现有功能。

- Drew Wills