雅格尼——不能命名的敏捷实践?[闭门]

TDD在某种程度上将雅格尼纳入其中。如果您正确地进行了TDD,也就是说,只编写产生所需功能的测试,然后开发最简单的代码来通过测试,那么默认情况下您遵循的是YAGNI原则。根据我的经验,只有当我跳出TDD的框框,在测试之前开始编写代码,测试我并不真正需要的东西,或者编写比通过测试更简单的代码时,我才违反了YAGNI。

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

YMMV。

Yagni和KISS(保持简单,愚蠢)本质上是相同的原则。不幸的是,我看到“吻”和“雅格尼”一样经常被提及。

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

改变的自由驱使着雅格尼 . 在瀑布项目中,咒语是控制范围。通过与客户签订合同来控制范围。因此,客户在范围文档中提供了他们所能想到的所有内容,他们知道一旦签订了合同,就很难对范围进行更改。因此,您最终得到的应用程序具有一系列功能,而不是一组有价值的功能。

在敏捷项目中,产品负责人构建一个优先的产品待办事项。开发团队基于优先级(即价值)构建特性。因此,最重要的东西首先要建造。最终得到的应用程序具有用户重视的功能。那些不重要的事情从清单上掉下来或者没有完成。那是雅格尼。

虽然YAGNI不是一种实践,但它是优先待办事项列表的结果。业务合作伙伴重视为业务提供的灵活性,因为他们可以在一个迭代到另一个迭代中更改产品待办事项并重新确定其优先级。这足以说明,雅格尼是当我们欣然接受变化时获得的好处,即使是在过程的后期。

我发现的问题是,人们甚至倾向于使用YAGNI下的DI容器(除非您的代码库中已经有了DI容器)编写工厂。我同意JB King的观点。对于许多与我共事过的人来说,YAGNI似乎是一个抄近路/编写草率代码的许可证。

例如,我正在编写一个PinPad API,用于抽象多个模型/制造商的PinPad。我发现,除非我掌握了整体结构,否则我甚至不能编写单元测试。也许我不是一个经验丰富的TDD实践者。我相信对于我所做的是否是雅格尼,会有不同的意见。

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