问题标签 [yagni]

在我看来，敏捷方法论鼓励我们保持简单、精简，而不是在需要时才增加复杂性和复杂性。但技术变革的速度和规模鼓励使用越来越抽象、复杂和复杂的工具和模式，以复杂的方式解决我们可能尚未（并且可能永远不会遇到）的问题，并具有显着的学习曲线和大量的努力投资。

我发现自己一直在打破这种模式。

YAGNI - 你不需要它

我只是一名初级开发人员，但我发现即使是高级开发人员也在做同样的事情。

“好吧，这个系统可能会使用它，还有这个，所以让我们为它设计吧。”

有时，我会抓住自己，但大多数时候我会狂奔。有没有人有任何坚持 YAGNI 的提示，或者我在设计和编码时可以做些什么来更好地执行这种设计模式？

对于我的软件开发编程课程，我们应该为 RSS 提要制作一个“提要管理器”类型的程序。这是我如何处理 FeedItems 的实现。

很好很简单：

我为此被标记了，“正确”的示例答案如下：

现在对我来说，这似乎很愚蠢。老实说，我不敢相信我被标记了，当这和我做的完全一样的事情时，我做的事情要多得多。

它让我想起在 C# 中人们总是这样做的：

我的意思是我知道他们为什么这样做，也许稍后他们想验证 setter 中的数据或在 getter 中增加它。但是，为什么你们不这样做，直到出现这种情况？

抱歉，这是一种咆哮，而不是真正的问题，但冗余让我抓狂。为什么 getter 和 setter 在不需要的时候如此受欢迎？

我通常将在赋值后只使用一次的变量值放入。我这样做是为了让以后的调试更方便，因为我可以将值悬停在稍后使用它的一行上。

例如，此代码不允许您悬停 GetFoo() 的值：

但是这段代码确实：

这闻起来很YAGNI式的，因为foo的赋值的功能在有人需要调试它的值之前永远不会被使用，这可能永远不会发生。如果不是为了仅仅预见到的调试会话，上面的第一个代码片段会使代码更简单。

您将如何编写代码以在简单性和调试器易用性之间取得最佳折衷？

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

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

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

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

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

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

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

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

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

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

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

大多数人都会同意，将现有应用程序国际化比从头开始开发国际化应用程序更昂贵。

这是真的吗？或者当你从头开始编写一个国际化的应用程序时，做 I18N 的成本只是被分摊在多个小任务上，没有人觉得他肩上的国际化任务的全部重量？

你甚至可以声称一个成熟的应用程序有许多在项目历史期间被删除的 LOC，如果事后考虑国际化，它们不需要 I18Ned，但如果项目国际化，它们就应该是 I18N从一开始。

那么，您是否认为从今天开始的项目必须国际化，或者该决定是否可以根据软件所享有的成功（或不成功）和需求的地理分布推迟到未来。

我不是在谈论操纵 unicode 数据的能力。您可以在大多数主流语言、数据库和库中免费使用。我说的是支持您自己的软件用户界面以多种语言和区域设置。

YAGNI 可以用过去时吗？您创建了一些功能，它在前一段时间使用过，但您不再使用它，并且您不想维护它，所以您宁愿将其删除。

摆脱未使用或很少使用的功能一定是一件坏事吗？

背景：

• 我使用源代码控制，所以如果我再次需要该功能，我可以得到它。
• 我是我的软件的唯一用户（我是分析数据集的生物信息学家）。
• 我遇到这种情况的一种情况是我使用继承，有一个父类和两个子类。一个是处理454测序产生的文件（下一代测序），另一个是处理Sanger测序产生的文件（上一代测序）。我在积极维护后者，但不是前者。也许我的错误是使用继承而不是组合，但这是一个稍微不同的故事。

现在，我有在我的主数据库访问类中创建数据库的代码（只是 SQLite 数据库上的几个 CREATE 查询）。这似乎没有必要，因为我无意使用该代码。如果出现问题并且我需要重新创建数据库，我只需要它。我是不是该...

1. 保持原样，即使数据库创建代码大约是我文件大小的四分之一。
2. 将数据库创建代码移动到单独的脚本中。如果我无论如何都需要再次运行它，我很可能会手动运行它，这会在处理主代码时让它看不见。
3. 如果我发现自己再次需要它，请删除数据库创建代码并依靠修订控制。

Pragmatic Programmer受到很多人的强烈推荐。我刚读完它，我明白人们为什么推荐它，尽管我要指出，Code Complete 涵盖了几乎所有相同的材料，而且更深入。

然而，困扰我的一件事是作者从未提及灵活性、概括性和为未来发展留出空间的任何缺点。这些概念都非常好，但是 YAGNI（You Ain't Gonna Need It）的原理发生了什么事，它可以防止开发人员浪费时间来实现永远不会使用的灵活性？

对 SO 的搜索显示了 400 个关于 YAGNI 的问题，所以我怀疑这个概念对作者来说太模糊了。当然，我远没有他们那么有经验，那他们为什么没有在整本书中提到任何克制的使用呢？

谢谢。

我听到的关于在面向对象设计中不遵守SOLID原则的最常见论点之一是YAGNI（尽管争论者通常不这么称呼它）：

“我可以将特征 X 和特征 Y 放在同一个类中。这很简单，为什么要麻烦添加一个新类（即复杂性）。”

“是的，我可以将我所有的业务逻辑直接放入 GUI 代码中，这样更容易、更快捷。这将永远是唯一的 GUI，而且不太可能出现重大的新需求。”

“如果在不太可能出现新需求的情况下，我的代码变得过于混乱，我仍然可以针对新需求进行重构。所以你的‘如果你以后需要……怎么办’的论点不重要。”

反对这种做法的最有说服力的论点是什么？我如何才能真正证明这是一种昂贵的做法，尤其是对于那些在软件开发方面没有太多经验的人。