YAGNI-不能命名的敏捷实践?[关闭]

TDD在某种程度上包含了YAGNI。如果你正确地进行TDD,也就是说,只编写那些产生所需功能的测试,然后开发最简单的代码来通过测试,那么你默认遵循YAGNI原则。根据我的经验,只有当我跳出TDD的框框,在测试之前开始编写代码,测试我并不真正需要的东西,或者编写超过通过测试的最简单方法的代码时,我才违反了YAGNI。

根据我的经验,后者是我在进行TDD时最常见的失礼行为——我倾向于跳到前面,开始编写代码以通过下一个测试。这通常会导致我基于我的代码而不是需要测试的内容的要求产生先入为主的想法,从而影响剩余的测试。

YMMV。

Yagni和KISS(保持简单,愚蠢)本质上是相同的原则。不幸的是,我看到KISS被提及的次数和我看到“yagni”的次数一样多。

在我所处的荒野地区,项目延误和失败的最常见原因是不必要组件的执行不力,所以我同意你的基本观点。

改变的自由驱使着YAGNI 在瀑布式项目中,核心原则是控制范围。通过与客户签订合同来控制范围。因此,客户在范围文件中尽其所能地填写,因为他们知道一旦合同签署,范围的变更将很困难。因此,您最终得到的应用程序具有一系列功能,而不是一组有价值的功能。

在敏捷项目中,产品负责人会构建一个优先级产品待办事项列表。开发团队根据优先级(即价值)构建功能。因此,最重要的东西会先建造。您最终会得到一个具有用户重视的功能的应用程序。不重要的事情从清单上掉下来或没有完成。这就是YAGNI。

虽然YAGNI不是一种实践,但它是优先级积压列表的结果。业务合作伙伴重视为业务提供的灵活性,因为他们可以在迭代中更改产品待办事项列表并重新确定其优先级。只要解释一下,YAGNI就是当我们欣然接受变化时所获得的好处,即使在过程的后期也是如此。

我在SO上看到了很多关于过早优化的帖子,这是yagni的一种形式,或者至少是ydniy(你还不需要它)。

我发现的问题是,人们倾向于在YAGNI下使用DI容器(除非你的代码库中已经有了)来编写工厂。我同意JB King的观点。对于我与YAGNI合作过的许多人来说,这似乎是偷工减料/编写草率代码的许可证。

例如,我正在编写一个PinPad API,用于抽象多个型号/制造商的PinPad。我发现,除非我有整体结构,否则我甚至无法编写单元测试。也许我不是一个经验丰富的TDD实践者。我敢肯定,对于我所做的是否是YAGNI,会有不同的看法。

我不认为YAGNI是快速和肮脏的对立面,真的。它只做需要做的事情,不再做更多的事情,而不是像一个人写的软件必须持续50年那样进行规划。它可能很少出现,因为围绕它没有那么多问题要问,至少在我看来是这样。类似于“不要重复自己”和“保持简单,愚蠢”的规则,这些规则变得普遍,但不一定以101种方式进行剖析和分析。有些事情很简单,通常在做了一点练习后很快就会得到。有些事情是在幕后发展起来的,如果你回头看,你可能会注意到它们可能是陈述事情的另一种方式。