design-patterns - 你对 YAGNI 有多远？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 提供事实和引用来回答它.

3年前关闭。




Improve this question




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

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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