问题标签 [yagni]

奇才可以启动功能。它们还可以混淆你的代码，并且是反 YAGNI 的。

总的来说，你认为巫师更有用还是更有害？

随着我越来越多地将敏捷思维吸收到我的工作方式中，yagni（“你不会需要它”）似乎变得越来越重要。在我看来，这似乎是过滤掉被误导的优先事项并决定下一步不做什么的最有效规则之一。

然而，yagni 似乎是一个在 SO 中几乎没有被提及的概念。我进行了强制性搜索，它只出现在一个问题标题中——然后是次要角色。

为什么是这样？我是否高估了它的重要性？

免责声明。为了抢占响应，我相信我会反对，让我强调一下 yagni 是quick-and-dirty 的对立面。它鼓励您将宝贵的时间和精力集中在获得您确实需要的零件上。

以下是人们可能会提出的一些热门问题。

我的单元测试是根据用户要求还是框架结构选择的？

我是否安装（并测试和维护）单元测试，因为它们脱离了框架？

有多少由我的框架生成的代码我从未看过（但总有一天可能会咬我，即使是 yagni）？

我花了多少时间在我的工具上而不是用户的问题上？

结对编程时，观察者的角色价值往往在于“yagni”。

你使用 CRUD 工具吗？它是否允许（不，鼓励）您将其用作 _RU_ 工具或 C__D 工具，或者当您只需要一两个代码时，您是否正在创建四段代码（加上四个单元测试）？

YAGNI “原则”指出，您不应该在需要之前专注于提供功能，因为无论如何“您不会需要它”。

无论如何，我通常倾向于在任何规则之上使用常识，但有时我觉得如果你有充分的理由，过度设计或未来证明某些东西是有用的，即使你可能永远不会使用它。

我现在手头的实际情况或多或少是这样的：

我有一个必须通过简单的专有通信协议（OSI 4 级）运行的应用程序。该协议具有一组理想的特性（例如遵循 NORM 规范），这些特性为应用程序提供了鲁棒性，但并非严格要求（UDP 多播可以执行可接受的）。

还有一个事实是，该应用程序将来可能（但不一定）被其他无法访问专有解决方案的客户使用，因此需要另一个解决方案。事实上，我知道该应用程序的另一个客户的可能性很高。

那么，你的想法是什么？我应该只为专有协议进行设计，然后将重构、接口提取等留到我真正需要的时候，还是应该现在就考虑（不是那么远）未来进行设计？

注意：为了清楚起见，我有兴趣听到对一般问题（何时违反 YAGNI）的各种意见，但我真的很想对我目前的困境提出一些建议或想法:)

他们矛盾吗？

解耦是一件很棒的事情，而且很难实现。然而在大多数应用程序中我们并不真正需要它，所以我可以设计高度耦合的应用程序，它几乎不会改变任何东西，除了明显的副作用，例如“你不能分离组件”，“单元测试是痛苦的屁股”等。

你怎么看？您是否总是尝试解耦并处理开销？

我已经阅读了很多关于 IoC 和 DI 的内容，但我并不真正相信在大多数情况下使用它们会收获很多。

如果您正在编写需要可插拔组件的代码，那么是的，我看到了它的价值。但如果你不是，那么我质疑将依赖项从类更改为接口是否真的为你带来了任何好处，除了更多的打字。

在某些情况下，我可以看到 IoC 和 DI 在哪些方面有助于模拟，但如果您不使用模拟或 TDD，那么它的价值是什么？这是 YAGNI 的案例吗？

如果可能有其他东西可以使用它，您应该始终创建一个接口，还是等到实际需要它然后重构以使用接口？

对接口进行编程通常似乎是合理的建议，但是还有 YAGNI ......

我想也许这取决于情况。现在我有一个对象代表一个可以包含食谱或其他文件夹的文件夹。我应该担心实现 IContainer 之类的东西，而不是直接使用 Folder 吗？以防将来我想要一个引用其他子食谱的食谱（比如一个苹果派食谱，它也是一个馅饼皮食谱的容器）

在代码中，通常很容易添加新类以提供附加功能等。我对重构代码及其所涉及的内容有相当好的理解，因此YAGNI通常对我来说是有意义的。

我不熟悉的是在部署后使用和更新关系数据库。我正在开发一个小宠物项目，我计划在早期发布，经常发布，我想知道我是否应该考虑在初始版本中不会使用但在计划功能列表中的数据? 添加表和调整架构是否像添加新类一样容易？或者我应该尝试为我可以想象使用但不打算在不久的将来使用的东西设置表格？

当我编写代码时，我只编写我需要的函数。

这种方法是否也适用于编写测试？

我应该提前为每个我能想到的用例编写一个测试，只是为了安全起见，还是应该只在遇到一个用例时为它编写测试？

天，

在这里思考这个关于为可能的未来变化进行过度设计的问题时，我开始思考。

你能向那些坚持吹嘘设计的人提供什么反对理由，因为“他们可能想在未来某个阶段在其他地方使用它”？

同样，当人们接受了要求，然后返回一个臃肿的设计，其中包含许多你没有要求的额外“花里胡哨”的东西时，你会怎么做？

当您知道扩展设计对现在或不久的将来存在的需求或可能的用途有意义时，我可以理解。而且我并不是在提倡只是愉快地接受要求列表并明确实施，而不提供任何关于您认为可能缺少的内容的反馈。

我说的是当人们坚持添加或拥有无关功能时该怎么办，以便“我们可能在未来某个阶段在其他地方使用它？”

在为新系统编写代码时，我不想在设计中引入我可能永远不需要的不必要的复杂性。所以我在这里关注 YAGNI，而是在我认为需要更多灵活性或职责变得更加清晰时进行重构。这让我可以更快地移动。

但是初级开发人员有一个问题，他们不知道何时重构或在哪里构建设计。他们只是在现有设计中塞进更多代码。

那么，解决这个问题的最佳方法是什么？我是否应该更频繁地构建一个更具前瞻性的设计，以便在添加时他们有一个很好的例子可以效仿，即使我们可能永远不需要添加任何东西？还是我应该继续进行更多的代码审查、教育等？或两者？

你们中有人遇到过这类问题吗？你是怎么解决的？