YAGNI - 不能命名的敏捷实践？

Question

随着我越来越多地将敏捷思维融入工作方式，yagni（“你不会需要它”）似乎变得越来越重要。在我看来，这是最有效的规则之一，用于过滤出被误导的优先事项，并决定接下来要处理的内容。

然而yagni似乎是一个在这里几乎没有耳语的概念。我运行了强制性搜索，它只显示在一个问题标题中 - 然后是次要角色。

这是为什么？我是否高估其重要性？

免责声明。为了抢先回应，我确信我会反对，让我强调yagni是与快速和肮脏的相反。它鼓励您将宝贵的时间和精力集中在获得您需要的零件上。

这里有一些可能会问的问题。

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

我是否安装（以及测试和维护）单元测试，因为它们脱离了框架而只出现在那里？

我的框架生成的代码有多少我从来没有看过（但仍然可能咬我一天，即使yagni）？

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

当配对编程时，观察者的角色值通常位于“yagni”中。

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

Answer 1

拓展署以某种方式包容了YAGNI。如果您正确执行TDD，即只编写那些会导致所需功能的测试，然后开发最简单的代码以通过测试，那么您默认遵循YAGNI原则。根据我的经验，只有当我跳出TDD框并开始在测试之前编写代码，测试我并不真正需要的东西，或者测试的代码不仅仅是通过测试的最简单的方法，我违反了YAGNI 。

在我的经验中，后者是我在做TDD时最常见的失礼 - 我倾向于跳跃前进，并开始编写代码以通过下一个测试。这通常会导致我通过基于我的代码创建一个先入为主的想法而不是需要测试的需求来影响剩余的测试。

YMMV。

Answer 2

我看过很多关于SO引用过早优化的帖子，这是yagni的一种形式，或者至少是ydniy（你现在还不需要它）。

Answer 3

Yagni和KISS（保持简单，愚蠢）基本上是相同的原理。不幸的是，我看到KISS经常提到我看到的“yagni”。

在我的荒野之地，项目延误和失败的最常见原因是不必要的部件执行不当，所以我同意你的基本观点。

Answer 4

我没有把YAGNI看作是快速和肮脏的反面，真的。它正在做所需要的，没有更多，也没有计划像有人写了50年的软件。它可能会很少发生，至少在我的脑海里并没有太多的问题要问。类似于“不重复自己”和“保持简单，愚蠢”的规则，这些规则变得很普遍，但不一定以101种方式进行解析和分析。有些东西很简单，通常在做一些练习后很快就会得到。有些事情在幕后发展，如果你回头看，你可能会注意到它们可能是另一种陈述事物的方式。

Answer 5

我发现的问题是，人们倾向于在YAGNI下使用DI容器（除非您已经拥有代码库中的代码）编写工厂。我同意JB King在那里。对于我与YAGNI合作的许多人来说，似乎是削减角落/编写草率代码的许可证。

例如，我正在编写一个PinPad API来抽象多个模型/制造商的PINPad。我发现，除非我有整体结构，否则我甚至不能写单元测试。可能是我不是一个经验丰富的TDD实践者。我确信对于我所做的是否是YAGNI会有不同的意见。

Answer 6

自由改变驱动器YAGNI。在瀑布项目中，咒语是控制范围。范围是通过与客户建立合同来控制的。因此，客户可以在范围文件中填写他们所能想到的全部内容，因为一旦合同签署后，范围变更将变得困难。因此，您最终得到的应用程序具有一系列功能，而不是一组具有价值的功能。

通过敏捷项目，产品所有者构建了优先级排序产品。开发团队根据优先级（即，价值）构建功能。结果，最重要的东西首先被建成。您最终得到的是具有用户重视功能的应用程序。不重要的东西从名单上掉下来或没有完成。那是YAGNI。

尽管YAGNI不是一种实践，但它是优先级积压列表的结果。业务合作伙伴重视提供业务的灵活性，因为他们可以将产品积压从迭代转换为迭代，并重新设置优先级。这足以解释YAGNI是我们在接受变革时所获得的利益，即使在这个过程的最后阶段也是如此。